diff --git a/content/blog/mail_server_alpine_postfix_dovecot_tutorial/index.md b/content/blog/mail_server_alpine_postfix_dovecot_tutorial/index.md index 21240ea..1059745 100644 --- a/content/blog/mail_server_alpine_postfix_dovecot_tutorial/index.md +++ b/content/blog/mail_server_alpine_postfix_dovecot_tutorial/index.md @@ -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. - +## 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: +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 + (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 +``` + +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: + + + + + + + + + + + + + + + + + + + + +
PolicyMeaning
noneDon't do anything if the DMARC check fails
quarantine + Quarantine emails if DMARC check fails; an admin must approve the email before it reaches the recipient's + inbox +
rejectReject the email if DMARC check fails
+ +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: + + + + + + + + + + + + + + + + + + + + + + +
OptionMeaning
0Generate reports if all authentication mechanisms fail
1Generate reports if any authentication mechanisms fail
dGenerate reports if DKIM authentication fails
sGenerate reports if SPF authentication fails
### Test SPF, DKIM, and DMARC @@ -1068,6 +1198,31 @@ and DMARC are all working for your server. ![Screenshot of mail-tester.com authentication results passing all checks](mail-tester_auth_results.png) +### 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. + [^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of