content/blog/mail_server_alpine_postfix_dovecot_tutorial.md: write dmarc section
This commit is contained in:
parent
f0a3232460
commit
4ff48c941a
GPG key ID:
3F257B68F5BC9339
1 changed files with 156 additions and 1 deletions
|
|
@ -1059,7 +1059,137 @@ 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
|
||||
emails relating to DKIM.
|
||||
|
||||
<!-- TODO DMARC section here -->
|
||||
## Domain-based Message Authentication, Reporting, and Conformance
|
||||
|
||||
### 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
|
||||
|
||||
|
|
@ -1068,6 +1198,31 @@ 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: -->
|
||||
|
||||
[^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of
|
||||
|
|
|
|||
Loading…
Reference in a new issue