No email configuration of any kind was found

What causes this

The domain resolves but publishes nothing related to email. If it is not used for mail, that is fine, though publishing a null MX and a restrictive SPF record is worth doing, because it stops the domain being an easy candidate for forgery. If it is meant to handle mail, nothing is configured yet.

What it breaks

The domain cannot receive mail, and because it publishes no policy, forged mail claiming to come from it faces no obstacle.

What the receiving server does

A receiver evaluating a message claiming to be from this domain finds no SPF record, so the SPF result is none. It finds no DMARC record, so there is no policy and no alignment requirement. Whatever DKIM signature is present, if any, is not tied to the visible From: address by any policy you published. The receiver falls back entirely to its own reputation heuristics, which for a domain with no sending history means the spoofed message is judged on the same basis as a genuine one.

The three records, whichever answer applies

There are two coherent configurations: a domain that sends and receives mail, and a domain that does neither and says so. The state to avoid is the third one, where nothing is published and the question is left open.

How to fix it

Either configure mail properly, or publish records that state the domain sends and receives none.

1. 01If the domain should handle mail, follow your provider's setup guide for MX, SPF and DKIM, then add DMARC.
2. 02If it should not, publish a null MX record, an SPF record of 'v=spf1 -all', and a DMARC record with p=reject.

v=spf1 -all

If you send with

If this domain sends mail

Start with SPF listing every sending service and DMARC at p=none with a reporting address. Read the reports for a few weeks, add anything you had forgotten, enable DKIM on every sending platform, then raise the policy in stages.

If this domain is parked or defensive

Lock it down in one sitting: v=spf1 -all, DMARC at p=reject, and a null MX. It takes minutes, requires no ongoing maintenance, and removes the domain from the pool of easy spoofing targets. Unused domains are attractive precisely because nobody is watching them.

If this domain only receives

Publish MX records and still publish SPF and DMARC. A receive-only domain that publishes v=spf1 -all and p=reject cannot be used to send mail in your name, which is the point.

Confirming the fix worked

1. 01Decide first whether the domain sends mail, receives mail, both, or neither. The correct configuration follows from that answer.
2. 02Publish SPF and DMARC in every case, including for domains that send nothing.
3. 03Where the domain sends, start DMARC at p=none with a reporting address rather than enforcing immediately.
4. 04Re-run the check and confirm each record resolves as intended.

Common questions

The domain does not send email. Why does it need SPF and DMARC?

Because a domain that sends no mail can still be used to send mail. Attackers prefer unused domains: there is no sending history to contradict them and usually nobody monitoring. Publishing v=spf1 -all and p=reject states clearly that nothing legitimate comes from here.

Which record should be published first?

SPF and DMARC at p=none together. SPF establishes who may send, DMARC starts the reporting that tells you whether the SPF record is complete. Enforcement comes after you have read the reports.

Does having no records mean mail from the domain will be rejected?

Not reliably. It means receivers have nothing to check against and fall back to reputation. Legitimate mail may be filtered on general suspicion, and spoofed mail may be delivered. Neither outcome is under your control.

How long does it take for the records to take effect?

As long as DNS propagation takes, typically minutes to a few hours depending on TTLs. DMARC aggregate reports begin arriving within 24 to 48 hours once a reporting address is published.