Reputation: 6052
Since 10th April, Stripe has mandated that non-Stripe domains sending email receipts must have DMARC enabled, following in the footsteps of Google and Yahoo:
To comply with this we implemented a DMARC policy via our mail provider, but not long after doing so other services that depend on our emails started to fail - such as Reviews.io's review invitation emails - likely because they don't yet support DMARC.
We've obviously made Reviews.io aware of this and after some work, it seems they've finally realised there's a problem and are trying to resolve things on their end. In the meantime, how can I enable DMARC while ensuring everything keeps working as it should?
Upvotes: -1
Views: 518
Reputation: 6052
To create a DMARC record, you create a DNS TXT record on the domain(s) you're sending emails from. This record must have a name of _dmarc
and a value consisting of DMARC tags - these make up your domain's DMARC policy.
For a bare minimum DMARC policy that shouldn't break anything else in the process:
v=DMARC1; p=none; ruf=mailto:[email protected];
The only required fields seem to be v
and p
, so if you didn't care about receiving failure (aka forensic) reports, you could even use:
v=DMARC1; p=none
This is the most complete list I can put together of the DMARC tags and what they do. Most are taken from DMARC.org but some appear to be undocumented.
Tag | Purpose | Example |
---|---|---|
v | Protocol version (required) | v=1 |
p | Policy for domains (required) | p=none |
sp | Policy for subdomains | p=none |
ruf | Target to send forensic reports | ruf=mailto:[email protected] |
rua | Target to send aggregate (daily) reports | rua=mailto:[email protected] |
ri | How often to send aggregate reports in seconds; default/minimum value is 86400 (24 hours) | ri=604800 |
pct | The percentage of emails to analyse; default is 100% | pct=20 |
adkim | Alignment mode for DKIM | adkim=r |
aspf | Alignment mode for SPF | aspf=r |
Some notes:
Both p
(and the optional sp
) can be set to none
for the least strict option. After some time has passed and DMARC is more widely implemented it's recommended that these are changed to either quarantine
(stricter) or reject
(most strict).
I dropped rua
after a while because I got tired of receiving daily aggregate reports from Google, Microsoft, and Yahoo that were of no actionable use to me, but left ruf
because I'd still like to know when things are failing. If you don't care about that either you could also drop ruf
. If you want to keep rua
but have aggregate reports sent less frequently, use ri
.
The optional adkim
and aspf
should be set to r
(relaxed) for the least strict option - this will allow subdomains in addition to the root domains of DKIM and SPF respectively. Note that Stripe doesn't currently support any value other than r
for aspf
.
DMARC aggregate reports (which default to being sent every 24 hours) currently only come in XML format, making them unreadable without further processing. There are services that help with this processing, such as dmarcian's online converter or URIports's very cheap automated monitoring, but unless you're a large organisation with a very complex mail setup you can probably get away with not receiving aggregated reports at all until you're trying to debug an issue or you start enforcing a more strict DMARC policy.
Upvotes: 1