Hashim Aziz
Hashim Aziz

Reputation: 6052

How to safely set up DMARC for Stripe

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:

enter image description here

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

Answers (1)

Hashim Aziz
Hashim Aziz

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

Related Questions