The domain you send from: SPF, DKIM and DMARC

A test that works proves the mail service accepted the message. Whether the receiving server then trusts it is decided by three DNS records on the domain of your From address, and a message that fails them is the one that "went" and landed in spam. Google asks every sender for SPF or DKIM, and Microsoft checks SPF, DKIM and DMARC on mail that high-volume senders send to Outlook.com.

Email Delivery → Dashboard → From Domain shows what those records say, one row each, with what was looked up, what came back and the one thing to do. The same panel sits under the result on Send a test. A record that receiving servers reject is marked Needs a change in red; one that is not there yet is Not found in amber.

• SPF lists the servers allowed to send for your domain. The panel reads the TXT record at your domain that starts with v=spf1. Two such records is an error to a receiving server, so it says to merge them. It follows the record's includes as deep as they go, as a receiving server does, and counts the terms that each cost a DNS lookup, every time they appear; over 10 is an error too, and it stops reading there. An include that leads to no SPF record, or is not a valid domain name (a typo such as two dots in a row), is an error to a receiving server as well, and the panel names it. So is a part of a record a receiving server cannot read at all, such as a + or a dot on its own, a dash pasted from a web page in place of -, or an address without ip4: in front: it rejects the whole record for it. Your own records are the ones at your From domain, at any name under it, and at the domains above it: for a From address at news.example.com, the records at news.example.com, mail.news.example.com and example.com. When the part is in one of those, the panel names the record and the part, in quotes; in a record a mail service runs, it names the include in your record that leads there and says to ask whoever runs it. A record that leads back to itself is an error too: an include or redirect= naming its own domain, or a record further down naming one on the way to it, however many records the loop passes through. A receiving server goes round that loop until it passes the limit, so the panel says Needs a change, however few lookups the rest of the record needs. When the loop closes in one of your own records, the panel names that record and the include (or redirect=) in it that leads back, in quotes and exactly as the record writes it, including a +, -, ~ or ? in front and a dot at the end. Taking out just that part ends the loop, and every record your From domain's record reached is still reached, so no server it lists is lost. For a From address at news.example.com whose record includes example.com, while the record at example.com includes news.example.com back, the part named is include:news.example.com in the record at example.com, and the subdomain keeps every server the main domain lists. If a record has that part more than once, take out every copy. When the loop closes in a record a mail service runs, which only that service can change, the panel names the include in your record that leads there and says to ask whoever runs it. A domain of yours with another name is treated as a service's. A loop long enough to pass 10 lookups before it comes round is shown as over the limit instead. A redirect= in a record that also ends in all is ignored, as receiving servers ignore it.
• For Gmail or Google Workspace, Microsoft 365, Mailgun, Mailjet, Zoho Mail and Fastmail the panel also looks for the include that service's own set-up page asks for (include:_spf.google.com, for example), names it if it is missing, and gives the whole record to add when there is none. Zoho's older include:zoho.com (or zoho.eu) counts as Zoho's. A record that lists addresses itself instead of includes, or uses macros (some managed SPF services do), is shown as found, with a note that whether it covers your service is not checked here.
• Mailgun recommends sending from a subdomain such as mg.example.com, and puts its SPF entry there. When the SMTP login in Settings is on a subdomain of your From domain (postmaster@mg.example.com), the SPF row reads that subdomain instead of your domain.
• SendGrid, Postmark, Brevo, SMTP2GO and Amazon SES send with a return address of their own, so receiving servers check SPF there. With one of those, no SPF record on your domain shows Not needed and is not offered as something to fix; a record that is there is still checked. For the web server or a mail server of your own, the panel says whether a record is there, and suggests asking your host or service what to add.
• DKIM is a signature your mail service adds, checked against a key it publishes on your domain. Where the service always uses the same name for it (google for Google Workspace unless you chose another, selector1 and selector2 for Microsoft 365, s1, s2 or m1 for SendGrid, mailjet for Mailjet, fm1 to fm3 for Fastmail) the panel looks it up. A name that points to the service (as Microsoft 365's do) but has no key behind it yet means signing was never switched on: the row says Not found and to turn it on. Every other service picks a name per account, so the row says Not checked and points you to that service's dashboard rather than guessing.
• DMARC tells receiving servers what to do with mail that fails the other two. The panel reads _dmarc. your domain (or, for a subdomain, the parent domain that covers it) and says the policy in plain words: none only asks for reports, quarantine asks for spam, reject asks for refusal. With no record it suggests starting with v=DMARC1; p=none.

If the From address is on a public mailbox (gmail.com, outlook.com, yahoo.com, icloud.com and the like, including their country domains such as hotmail.co.uk, live.fr or yahoo.es) and the site sends through anything but that mailbox's own server, the panel warns that the mailbox provider's rules decide, and that an address on your own domain works better. That provider's own records are not looked up, because you cannot change them.

When SPF or DMARC is missing or wrong, Worth doing next on the Dashboard says so: "Set up" when a record is not there, "Fix" when one is there and wrong. DKIM is left to the panel.

When it is checked. Once a day, when you save (or import) a new From address, mail service, mail server or SMTP login, after each Send a test, and whenever you press Check again. It is never checked while a message is being sent, and never on a visitor's visit. The lookups go to your own server's DNS resolver and nowhere else: no outside service is told your domain. DNS answers can be cached for a while, so a record you have just added may take some time to show; the panel says when it last looked. If your host does not let WordPress look up DNS records, every row says Could not look up. If the From address has no domain that can be looked up, the rows say so instead.

What it does not do: it changes nothing about how mail is sent, and a row that says Found is not a promise that every message reaches the inbox. It checks the domain of the From address in Settings (or, with none set, the address WordPress makes up); a plugin that sends from an address of its own is not checked. Apart from Mailgun's subdomain above, a service that sends for a subdomain of yours is checked on your From domain, not on that subdomain.