Compare commits
No commits in common. "20b77e01e8a6cb00fce40798e243f2437d4a99ae" and "317df859c0f551db5fdfca28fbbc389488c67e0c" have entirely different histories.
20b77e01e8
...
317df859c0
1 changed files with 1 additions and 156 deletions
|
|
@ -1059,137 +1059,7 @@ non_smtpd_milters = $smtpd_milters
|
||||||
This uses the Milter extension, which is something that can be used to process mail; in this case, to add headers to
|
This uses the Milter extension, which is something that can be used to process mail; in this case, to add headers to
|
||||||
emails relating to DKIM.
|
emails relating to DKIM.
|
||||||
|
|
||||||
## Domain-based Message Authentication, Reporting, and Conformance
|
<!-- TODO DMARC section here -->
|
||||||
|
|
||||||
### Ensure your domains are aligned in email headers
|
|
||||||
|
|
||||||
Send a test email from your domain and look at the email headers of the sent email.
|
|
||||||
|
|
||||||
``` {hl_lines=[1,11,23]}
|
|
||||||
Return-Path: <pid1@revsuine.xyz>
|
|
||||||
Received: from master.revsuine.xyz (master.revsuine.xyz. [93.113.25.226])
|
|
||||||
by mx.google.com with ESMTPS id ffacd0b85a97d-3825fb5a132si1538595f8f.66.2024.11.22.08.53.01
|
|
||||||
for <revsuine@gmail.com>
|
|
||||||
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
|
|
||||||
Fri, 22 Nov 2024 08:53:01 -0800 (PST)
|
|
||||||
Received-SPF: pass (google.com: domain of pid1@revsuine.xyz designates 93.113.25.226 as permitted sender) client-ip=93.113.25.226;
|
|
||||||
Authentication-Results: mx.google.com;
|
|
||||||
dkim=pass header.i=@revsuine.xyz header.s=default header.b=HRewRpbu;
|
|
||||||
spf=pass (google.com: domain of pid1@revsuine.xyz designates 93.113.25.226 as permitted sender) smtp.mailfrom=pid1@revsuine.xyz;
|
|
||||||
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=revsuine.xyz;
|
|
||||||
s=default; t=1732294380;
|
|
||||||
bh=Q6d5/50T+3BnL4k+i/ARiher4CIHkBrfcsHufAU/i4E=;
|
|
||||||
h=Subject:From:To:Date;
|
|
||||||
b=HRewRpbuXhaI4vf8ZXc0PzepcNAd5mGDvWh38mAF+JYvefM7pF+q0dNYrA0bCrCys
|
|
||||||
a6qev9C++7hJC7oLYKgcXoewHPiGQzfgjj5oIVuIE10CSuSNyk4vd4Nf37P8k1A8lO
|
|
||||||
jy+g+kv7VbX5N+ElzQbqXL1PTjgd9seDYoPn5FTTWGfVbLhh6gWfU3xeb88UZQCFJ+
|
|
||||||
kgWMFOUEjoTffzqNBe/NICvcoX3ZJvr+vCdZVANHEV1AhVExDB9FM/0TRFnybhTVo0
|
|
||||||
eGDCEtvkxgNQYVFVnJUxWZ3MCt+cDVuYVsHw0SXQMToiNSPlsn65iV2+/giw7DmSCo
|
|
||||||
fgOvYG+eHu10w==
|
|
||||||
Message-ID: <47971a581909651b6e089287b5b408fd56352b82.camel@revsuine.xyz>
|
|
||||||
Subject: Test
|
|
||||||
From: revsuine <pid1@revsuine.xyz>
|
|
||||||
```
|
|
||||||
|
|
||||||
Ensure that the domains in `Return-Path`, `DKIM-Signature`, and `From:` are the same. If they are, they are strictly
|
|
||||||
aligned. Or if the `Return-Path` or `DKIM-Signature`'s `d=` parameter use a subdomain instead of the main domain name
|
|
||||||
in the `From:` field, they have relaxed alignment. Either way, they are aligned.
|
|
||||||
|
|
||||||
By default, DMARC uses relaxed alignment. Your domains have to be aligned in order to pass DMARC checks.
|
|
||||||
|
|
||||||
### Create a DMARC DNS record
|
|
||||||
|
|
||||||
Create a TXT record with `_dmarc` as the record name, and
|
|
||||||
|
|
||||||
```
|
|
||||||
v=DMARC1; p=none; pct=100; fo=1; rua=mailto:dmarc@domain.com
|
|
||||||
```
|
|
||||||
|
|
||||||
as the TXT data, replacing `dmarc@domain.com` with an email address you want mail servers to send their DMARC reports
|
|
||||||
to.
|
|
||||||
|
|
||||||
#### Policies
|
|
||||||
|
|
||||||
`p=none` indicates the policy for our DMARC record. The available policies are:
|
|
||||||
|
|
||||||
<!-- yk the drill, html table for line breaks -->
|
|
||||||
|
|
||||||
<table>
|
|
||||||
<tr>
|
|
||||||
<th>Policy</th>
|
|
||||||
<th>Meaning</th>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>none</code></td>
|
|
||||||
<td>Don't do anything if the DMARC check fails</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>quarantine</code></td>
|
|
||||||
<td>
|
|
||||||
Quarantine emails if DMARC check fails; an admin must approve the email before it reaches the recipient's
|
|
||||||
inbox
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>reject</code></td>
|
|
||||||
<td>Reject the email if DMARC check fails</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
|
|
||||||
It's recommended to start with `none` or `quarantine` until you're sure that your emails are passing DMARC. `none` is
|
|
||||||
more appropriate for domains that have already sent some emails; if you've never sent email from your domain before,
|
|
||||||
try `quarantine` with `pct=30` (see below) as a start.
|
|
||||||
|
|
||||||
If your domain is not going to send emails, set `p=reject`.
|
|
||||||
|
|
||||||
#### Percentage
|
|
||||||
|
|
||||||
`pct=100` means that a mail server should expect 100% of incoming mail from your domain to pass DMARC checks. As you
|
|
||||||
increase the strictness of your policy, you should also decrease `pct` until you are sure that your email is passing
|
|
||||||
checks.
|
|
||||||
|
|
||||||
[LinuxBabe](https://www.linuxbabe.com/mail-server/create-dmarc-record) recommends the following "progression", moving
|
|
||||||
to the next row in the table as you've tested the previous row and haven't seen legitimate mail rejected:
|
|
||||||
|
|
||||||
| Policy | Percentage |
|
|
||||||
| ------------ | ---------- |
|
|
||||||
| `none` | 100 |
|
|
||||||
| `quarantine` | 30 |
|
|
||||||
| `quarantine` | 70 |
|
|
||||||
| `quarantine` | 100 |
|
|
||||||
| `reject` | 30 |
|
|
||||||
| `reject` | 70 |
|
|
||||||
| `reject` | 100 |
|
|
||||||
|
|
||||||
#### Email reports
|
|
||||||
|
|
||||||
You set an email address for DMARC reports to be sent to with `rua=mailto:dmarc@domain.com`. This means that when a
|
|
||||||
mail server receives email from your domain, if it runs a DMARC check, it will send the results to that email.
|
|
||||||
|
|
||||||
The `fo` tag indicates when you would like to receive reports. The options are:
|
|
||||||
|
|
||||||
<table>
|
|
||||||
<tr>
|
|
||||||
<th>Option</th>
|
|
||||||
<th>Meaning</th>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>0</code></td>
|
|
||||||
<td>Generate reports if <strong>all</strong> authentication mechanisms fail</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>1</code></td>
|
|
||||||
<td>Generate reports if <strong>any</strong> authentication mechanisms fail</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>d</code></td>
|
|
||||||
<td>Generate reports if DKIM authentication fails</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><code>s</code></td>
|
|
||||||
<td>Generate reports if SPF authentication fails</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
|
|
||||||
### Test SPF, DKIM, and DMARC
|
### Test SPF, DKIM, and DMARC
|
||||||
|
|
||||||
|
|
@ -1198,31 +1068,6 @@ and DMARC are all working for your server.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Failure
|
|
||||||
|
|
||||||
There are a few things that can cause SPF, DKIM, and consequently DMARC to fail.
|
|
||||||
|
|
||||||
One common scenario is email relaying causing SPF to fail, because the recipient mail server does not receive the email
|
|
||||||
directly from your mail server.
|
|
||||||
|
|
||||||
#### Mailing Lists
|
|
||||||
|
|
||||||
"Announcement" type mailing lists can cause DKIM failure, because usually additional headers are added to your emails.
|
|
||||||
"Discussion" type mailing lists are more problematic; they can also cause SPF failures because emails are coming from
|
|
||||||
all different mail servers through the mailing list server, and the central mailing list server cannot sign other
|
|
||||||
domain's DKIM signatures.
|
|
||||||
|
|
||||||
For announcements, if you are using an external mailing list provider, just add their server to your SPF record. For
|
|
||||||
discussion mailing lists, resolving authentication issues is more complex. [GNU Mailman has a wiki article with some
|
|
||||||
suggestions.](https://wiki.list.org/DEV/DMARC)
|
|
||||||
|
|
||||||
# Amavis
|
|
||||||
|
|
||||||
# Miscellaneous suggestions
|
|
||||||
|
|
||||||
You may want to get your domain whitelisted on [dnswl.org](https://www.dnswl.org/), an email whitelist service where
|
|
||||||
admins can submit their domain and IP address to indicate trustworthiness.
|
|
||||||
|
|
||||||
<!-- FOOTNOTES: -->
|
<!-- FOOTNOTES: -->
|
||||||
|
|
||||||
[^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of
|
[^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue