finished the page
This commit is contained in:
parent
8ea80aa035
commit
3efe50473b
1 changed files with 46 additions and 20 deletions
|
|
@ -388,10 +388,9 @@ domain that only consists of the rightmost two parts. For `mails.hawkeye.example
|
||||||
|
|
||||||
## DMARC
|
## DMARC
|
||||||
|
|
||||||
DMARC wants to make sure that the _visible sender_ (what the user sees in the mail program) **matches** the _envelope
|
### Example
|
||||||
sender_. SPF and DKIM only verify the _envelope sender_. But that does not provide any value to the user.
|
|
||||||
|
|
||||||
Let's take a simplified example header **without** DMARC:
|
Let's take an example header of a spoofed mail:
|
||||||
|
|
||||||
```
|
```
|
||||||
Return-Path: <noreply@evil-spammer.com>
|
Return-Path: <noreply@evil-spammer.com>
|
||||||
|
|
@ -401,26 +400,53 @@ From: <service@paypal.com>
|
||||||
|
|
||||||
In this example a bad guy just sent you this email. The SPF check for the `evil-spammer.com` domain was successful. (You
|
In this example a bad guy just sent you this email. The SPF check for the `evil-spammer.com` domain was successful. (You
|
||||||
can't see that from these headers though.) He even added a DKIM signature from his domain. So everything looks right.
|
can't see that from these headers though.) He even added a DKIM signature from his domain. So everything looks right.
|
||||||
But you just see a properly verified email from `service@paypal.com`. This is bad.
|
But in your mail program you see `service@paypal.com`. So nobody checks that the _envelop sender_ and the _visible
|
||||||
|
sender_ "align".
|
||||||
|
|
||||||
---
|
### How it works
|
||||||
|
|
||||||
DMARC is a mess. Most explanations (including my own from earlier guides) are wrong or incomplete. The Wikipedia page is
|
That's what DMARC is supposed to solve. It works like this:
|
||||||
useless. Its acronym _Domain-based Message Authentication, Reporting and Conformance_ sounds like it was invented by a
|
|
||||||
random word generator.
|
|
||||||
|
|
||||||
But what if someone sends an email in your name but does not add a DKIM signature? Would it be rejected? No, it would
|
- (A) SPF
|
||||||
not. With DKIM you can prove that you sent the email. And other people cannot fake it without access to your DNS zone.
|
- Run a normal **SPF** check (on the _envelope sender_'s domain as usual)
|
||||||
|
- Make sure that the domain of this _envelope sender_ **aligns** with (matches) the domain of the _visible sender_
|
||||||
|
- (B) DKIM
|
||||||
|
- Look for a valid **DKIM** signature (also of the _envelope sender_'s domain)
|
||||||
|
- Make sure that the domain of the _envelope sender_ **aligns** with (matches) the domain of the _visible sender_
|
||||||
|
- Make sure that **at least one** of (A) or (B) are true
|
||||||
|
|
||||||
I mentioned that DMARC is the newer standard. So why use SPF anyway? Because some email providers value your effort if
|
There are also two flavors of that _alignment_:
|
||||||
you use SPF, too. Technically it’s sufficient to specify a DMARC entry. In my opinion restricting the IP addresses
|
|
||||||
allowed to send is a little dangerous and a little inflexible. It is far more interesting to require that emails from
|
|
||||||
your domain have a valid DKIM signature. Such a record may look like:
|
|
||||||
|
|
||||||
```
|
- **strict** means that the domains need to match exactly
|
||||||
"v=DMARC1; p=reject; adkim=s; ruf=postmaster@example.org"
|
- **relaxed** means that it can be a subdomain
|
||||||
```
|
|
||||||
|
|
||||||
However to create a proper DMARC entry I suggest you use [one of](http://www.kitterman.com/dmarc/assistant.html)
|
You can find more examples about the _alignment_ in the [RFC 7489](https://www.ietf.org/rfc/rfc7489.txt) in Appendix
|
||||||
[the](https://dmarcian.com/dmarc-inspector/) [web](https://www.unlocktheinbox.com/dmarcwizard/)
|
B.1.
|
||||||
[sites](https://www.agari.com/resources/tools/dmarc) that aid you there and explain the restrictions and extra features.
|
|
||||||
|
### Reporting
|
||||||
|
|
||||||
|
Another feature of DMARC is reporting. You may want to know whether your emails had delivery problems. DMARC has two
|
||||||
|
tags for that purpose:
|
||||||
|
|
||||||
|
- **ruf** stands for "**R**eporting **U**RI for **F**ailure data". The email address you use in the "ruf" tag will get
|
||||||
|
machine-readable information on every mail that failed the DMARC test. If the receiving mail server supports DMARC, it
|
||||||
|
**may** automatically generate and send that email to this address. However most internet providers just ignore "ruf"
|
||||||
|
because it contains sensible information on email addresses.
|
||||||
|
- **rua** stands for "**R**eporting **U**RI for **A**ggregated data". The email address you use in the "rua" tag will
|
||||||
|
get statistical data usually once a day. If you want to know if your emails deliver properly, you can use this.
|
||||||
|
|
||||||
|
There are commercial offers that allow you to point your "rua" record to their service and show you human-readable
|
||||||
|
information. Or you can use the tools `dmarc-cat` or `dmarcts-report-parser` that can be installed as Debian packages on
|
||||||
|
your system.
|
||||||
|
|
||||||
|
### Creating a record
|
||||||
|
|
||||||
|
If you want to use DMARC (and I suggest that you do), just add a DNS record to your domain. These web sites help you
|
||||||
|
craft a valid record:
|
||||||
|
|
||||||
|
- http://www.kitterman.com/dmarc/assistant.html
|
||||||
|
- https://dmarcian.com/dmarc-inspector/
|
||||||
|
- https://www.unlocktheinbox.com/dmarcwizard/
|
||||||
|
- https://www.agari.com/resources/tools/dmarc
|
||||||
|
|
||||||
|
Please note that the DMARC record is a TXT record like `_dmarc.example.com`. That `_dmarc` host name is important.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue