Email authentication check

Your app sends mail. A sign in code, a password reset, a receipt. Whether that mail is believed has almost nothing to do with your code and almost everything to do with two records published in the domain name system. SPF lists the servers allowed to send mail for your domain. DMARC tells the receiving side what to do when a message fails that test, and where to report it.

This is the one part of a launch that no coding agent will ever fix for you, because it does not live in the repository. It lives with whoever holds your domain. So it gets skipped. The app is finished, the mail provider is connected, the first test message arrives, and the job looks done. Nobody checks what a receiving server thinks of it.

The cost shows up in two directions. Outbound, your password reset lands in spam and the person who wanted to use your product quietly leaves. That is the failure you never hear about, and it happens most often on the exact message that matters most. Inbound, a domain with no DMARC policy is a domain anybody can send mail as, which is how a convincing message from your own address reaches your own customers.

This tool reads the records published for your domain and reports what is there, what is missing, and what a policy set to none actually means in practice. It reads public DNS only. It does not send mail, does not connect to your mail provider and cannot tell you whether a given message was delivered. That is one check of sixteen, and it is usually the fastest one to fix, because it is a single record and a wait for the change to spread.

This page is for running the check. The finding page explains the issue itself, and it is the page to read or link when you want the explanation rather than the test. Read the finding page.