Your alert email probably has one leg holding it up

We read our own DMARC report properly and found every message passing on a single mechanism. If that one DNS record ever breaks, every alert we send lands silently in spam.

A DMARC aggregate report arrived and we read one properly for the first time. Four messages, three sources, every one passing. Then we looked at how they were passing.

Every alert this product sends goes out through Amazon SES, and SES passes DMARC for us on exactly one mechanism: DKIM. SPF alignment fails every time, and it will keep failing, because by default SES uses its own domain as the envelope return path. SPF is evaluated against that domain rather than ours, and DMARC requires the domain SPF checked to align with the domain in the From header. Those two can never match under the default configuration.

Which means the include for amazonses.com in our SPF record was doing nothing for DMARC at all. It is one of the most common mail misconfigurations we have seen confidently described as correct, including in our own setup notes.

Our published DMARC policy is quarantine. So if that single DKIM record is ever removed, rotated, or invalidated by re-verifying the sending identity, every alert we send silently lands in a spam folder. Not bounces — spam. The sender is told nothing, and the recipient never looks. For a product whose entire value is an alert arriving, and where most accounts have no second delivery channel configured, that is one leg holding up the whole thing.

The fix is a custom MAIL FROM domain: a subdomain with its own MX record and its own SPF record, configured on the sending identity so the return path lives on your domain instead of the provider's. Then SPF aligns too, and the two mechanisms become independent. Either one failing leaves the other standing.

There is a real footgun in that change and it is worth naming before you make it. The behaviour on MX failure has two settings. One rejects every outbound message if the DNS is not resolvable, and one silently falls back to the provider domain. The first turns a DNS mistake into a total mail outage. The second turns it into exactly the situation you were trying to leave, without telling you.

So the last piece is monitoring, and it is the piece most teams skip. We now ask the provider directly, on a schedule, whether the sending identity is verified, whether DKIM is still active, and whether the MAIL FROM domain still resolves — and page an operator when the answer changes. Not a synthetic test message. The provider's own answer about its own state.

Two things will tell you where you stand. Read one DMARC aggregate report for your own domain and look at the alignment result for each mechanism separately rather than the overall pass. Then check whether a custom MAIL FROM domain is configured on your sending identity. If it is not, and your policy is quarantine or reject, your transactional mail is standing on one leg too.

This article is about a shipped surface: All product surfaces. Integration details live in the docs.