Check your email domain's SPF, DKIM and DMARC

Also reported as: Null MX; 550 5.7.27 Sender address has null MX; Domain does not accept mail

A single MX record of 0 . (RFC 7505) declares that the domain never receives mail. Receivers may refuse mail that uses the domain as its sender, with 550 5.7.27, and replies and bounces to it have nowhere to go.

1. If the domain sends mail, delete the 0 . record and publish the MX records your mailbox provider gives you, such as example.com. MX 10 mx1.mailhost.example.
2. If the domain really never sends or receives mail, keep the null MX and send from a domain or subdomain that has real MX records.
3. Check again once the old record's TTL has passed.

Also reported as: MX record missing; Implicit MX; Mail falls back to the A record

With no MX record, servers deliver mail for the domain to its A or AAAA address instead (RFC 5321 §5.1). That is usually a web server that doesn't accept mail, so replies to your messages and bounces sent to the domain fail or go somewhere nobody reads.

1. Publish the MX records from your mailbox provider at the domain: example.com. MX 10 mx1.mailhost.example.
2. Make sure the Return-Path domain can take bounces. Providers that use their own return-path subdomain publish an MX there; Unitpost asks for one on unitpost.<your domain>.
3. Check again.

Also reported as: Sender address rejected: Domain not found; Sender domain has no MX record; Domain does not resolve

The domain has neither MX nor address records, so no server can deliver to it. Receivers that check whether a sender's domain can receive mail refuse messages from it, and bounces have nowhere to go.

1. Check the spelling of the domain you entered and of the one in your From address.
2. Confirm the domain is registered and delegated: dig NS example.com +short should list your DNS host's nameservers.
3. Publish MX records from your mailbox provider: example.com. MX 10 mx1.mailhost.example.

Also reported as: BIMI record; default._bimi TXT record

A v=BIMI1 record at default._bimi.<domain> points to a logo that supporting inboxes show beside your authenticated mail. The record alone isn't enough: Gmail also needs DMARC at quarantine or reject applied to all mail, and a mark certificate (a VMC or a CMC) from a certificate authority.

1. Check the shape: v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/mark.pem, with both URLs on HTTPS.
2. Keep DMARC at p=quarantine or p=reject, with no pct below 100.
3. Get the logo in SVG Tiny PS format and the certificate from the issuing authority; logos can take a couple of days to appear after the record is published.

Also reported as: BIMI requires DMARC enforcement; DMARC policy is not at enforcement

BIMI is published, but the domain's DMARC policy is p=none, missing, or uses pct below 100. Inboxes that support BIMI show the logo only when DMARC is quarantine or reject for all mail.

1. Confirm in your DMARC aggregate reports that every legitimate source passes with alignment.
2. Move the policy to p=quarantine, then p=reject, and remove any pct tag so it applies to all mail.
3. Check the domain again; the warning clears once the policy is enforced.

Also reported as: MTA-STS; _mta-sts TXT record

A v=STSv1 record at _mta-sts.<domain> tells servers that support MTA-STS (RFC 8461) to fetch your policy and deliver to you only over TLS with a valid certificate. This check sees the TXT record only. The policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt sets the mode, and senders enforce it only when it says mode: enforce.

1. Open the policy file in a browser and confirm it lists every MX host on an mx: line and the mode you intend.
2. Run mode: testing with TLS-RPT turned on until the reports show no failures, then switch to mode: enforce.
3. Change the id= value in the TXT record every time you edit the policy file, or senders keep using the copy they cached.

Also reported as: SMTP TLS reporting; _smtp._tls TXT record

A v=TLSRPTv1 record at _smtp._tls.<domain> (RFC 8460) asks servers that deliver to you to send reports of TLS failures they hit, usually one a day per reporting organization.

1. Check the shape: v=TLSRPTv1; rua=mailto:tls-reports@example.com.
2. Point it at a mailbox or service that can take machine-readable JSON reports, often compressed.
3. Read the reports before you move MTA-STS from testing to enforce.

Also reported as: SERVFAIL; DNS timeout; SPF temperror; Couldn't read TXT records

The resolvers answered with an error, or not at all, so the check couldn't tell whether the record exists. Receivers that hit the same error get a temporary error (temperror) and usually defer your mail until it clears.

1. Run the check again in a minute; a one-off timeout clears by itself.
2. Ask your nameservers directly: dig NS example.com +short, then dig TXT example.com @<one of those nameservers>. A nameserver that doesn't answer needs fixing at your DNS host.
3. If every lookup returns SERVFAIL, check DNSSEC. A DS record at your registrar that no longer matches the zone's keys, common after moving DNS hosts, makes validating resolvers fail every query. Update or remove the DS record.