SPF and DMARC help receiving mail systems decide whether an email using your domain is genuine. Checking the records means looking up two DNS entries, confirming they are valid, and then making sure every legitimate sender is correctly authenticated and aligned.
That last part matters. A record can exist, look plausible, and still leave a domain open to impersonation — or cause genuine messages to be rejected.
Use Wuluf's Domain Security Check to inspect the live SPF and DMARC records published for your domain. This guide explains what the results mean, which problems to look for, and what to do next.
Identify every service that sends email using your domain. This may include Microsoft 365 or Google Workspace, but also marketing platforms, CRM systems, support desks, invoicing tools, recruitment software and website forms. An incomplete change can interrupt legitimate email.
What are SPF and DMARC?
SPF and DMARC are email-authentication controls published as TXT records in the Domain Name System (DNS).
SPF, or Sender Policy Framework, lists the servers and services authorised to send email on behalf of a domain. When a message arrives, the receiving system can compare the sending server with the domain's published SPF policy.
DMARC, or Domain-based Message Authentication, Reporting and Conformance, builds on SPF and DKIM. It checks whether an authenticated domain aligns with the domain visible in the email's From address. It also tells receiving systems what to do when authentication fails, and can send reports back to the domain owner.
In practical terms:
- SPF answers: is this server authorised to send for this domain?
- DKIM answers: does this message carry a valid cryptographic signature?
- DMARC answers: does the authenticated identity match the domain the recipient sees, and what should happen if it does not?
DMARC passes when at least one aligned authentication method — SPF or DKIM — passes. SPF and DKIM can therefore appear to pass independently while DMARC still fails, because the domains do not align.
How to check your SPF record
The quickest option is to enter your domain into Wuluf's Domain Security Check. You can also query your DNS directly and look for a TXT record beginning v=spf1.
A simple record might resemble:
v=spf1 include:example-email-provider.com -all
This example says that the named provider is authorised to send email for the domain. The -all mechanism states that other sources are not authorised. Your real record may contain several authorised services, IP addresses or other mechanisms.
When reviewing the result, ask:
- Is an SPF record present?
- Is there exactly one SPF record for the domain?
- Does it include every legitimate sending service?
- Does it contain valid syntax?
- Does evaluation remain within SPF's DNS-lookup limit?
- Does the final mechanism reflect the organisation's intended policy?
Finding v=spf1 is not, by itself, a clean bill of health.
Common SPF problems and how to fix them
1. No SPF record
What it means: the domain has not published a policy identifying its authorised sending systems.
What to do: create a TXT record using the instructions supplied by each legitimate email provider. Build the record from a verified inventory of sending services rather than copying a generic example.
2. Multiple SPF records
What it means: more than one TXT record begins with v=spf1. SPF does not allow several separate policies to be combined during evaluation, so this can produce a permanent error.
What to do: consolidate all legitimate sending sources into one valid SPF record. Do not simply delete one until its authorised senders have been accounted for.
3. A legitimate sender is missing
What it means: your main email platform may be authorised, but another system — such as a CRM, marketing platform or website service — is not.
What to do: inventory every system that sends using your domain. Add the mechanism recommended by the provider, then test it. DMARC aggregate reports can help identify sending sources that were previously overlooked.
4. Too many DNS lookups
What it means: SPF evaluation is limited to ten DNS-querying mechanisms and modifiers. Nested include statements count towards the total and can hide additional lookups. Exceeding the limit can return a permerror.
What to do: remove services that no longer send mail, simplify unnecessary mechanisms, and review nested includes. Be cautious with automated SPF flattening — provider infrastructure can change, so any approach that replaces provider records with fixed IP addresses needs maintenance and monitoring.
5. Syntax errors
What it means: a typo, unsupported mechanism, misplaced character or invalid value prevents the record from being interpreted as intended.
What to do: validate the complete record, compare every third-party entry with the provider's current documentation, and correct the record through your DNS provider.
6. An unsuitable "all" mechanism
The end of an SPF record commonly contains one of these mechanisms:
-all— sources that do not match should fail SPF~all— sources that do not match return a soft fail?all— no assertion is made about unmatched sources+all— every sender is authorised, which defeats the purpose of SPF and should not be used as a normal policy
Moving from ~all to -all should be based on evidence that legitimate senders are covered. It should not be treated as a cosmetic improvement to a DNS score.
How to check your DMARC record
DMARC is normally published as a TXT record at _dmarc.yourdomain.co.uk.
A monitoring policy might resemble:
v=DMARC1; p=none; rua=mailto:[email protected]
Check it using Wuluf's Domain Security Check, or perform a TXT lookup for the _dmarc hostname.
Review the following:
- Is the record published at the correct
_dmarchostname? - Is there only one DMARC record?
- Is the syntax valid?
- Is a policy present:
p=none,p=quarantineorp=reject? - Are aggregate reports configured using
rua? - Are SPF and/or DKIM aligned with the visible From domain?
- Are subdomains covered appropriately?
- Has the organisation validated legitimate senders before enabling enforcement?
What do p=none, p=quarantine and p=reject mean?
The p tag states the requested treatment of messages that fail DMARC:
- p=none requests monitoring without asking the receiver to quarantine or reject failing messages
- p=quarantine asks receivers to treat failing messages as suspicious, commonly by routing them to spam
- p=reject asks receivers to reject messages that fail DMARC
A p=none record gives visibility, but it does not ask receiving systems to block spoofed mail. It is usually a deployment stage, not the desired final security posture.
Equally, publishing p=reject without understanding your sending estate can block genuine messages. Enforcement should follow analysis, remediation and testing.
Common DMARC problems and how to fix them
1. No DMARC record
What it means: the domain has not published instructions for messages that fail aligned email authentication, and the owner receives no DMARC aggregate reporting.
What to do: begin with a correctly configured monitoring policy and a managed mailbox or reporting platform capable of processing aggregate reports. Identify legitimate and unauthorised sending sources before progressing towards enforcement.
2. The record is published in the wrong place
What it means: a DMARC policy placed against the root domain instead of _dmarc will not be discovered correctly.
What to do: publish the TXT record at _dmarc.yourdomain using the exact format required by your DNS provider.
3. SPF or DKIM passes, but DMARC fails
What it means: authentication succeeded, but the authenticated domain does not align with the domain in the visible From address. For SPF alignment, the authenticated envelope-from domain must align with the visible From domain. For DKIM alignment, the domain in the DKIM signature's d= value must align with it.
What to do: configure legitimate third-party platforms to use an aligned return-path, an aligned DKIM signing domain, or both. The exact controls depend on the service.
4. Remaining permanently at p=none
What it means: reports may be collected, but the published policy does not ask receivers to quarantine or reject messages that fail DMARC.
What to do: use the reports. Classify each sending source, correct legitimate failures, and remove or investigate unknown sources. Progress deliberately towards p=quarantine and then p=reject when the evidence supports it.
5. Reports are configured but not reviewed
What it means: XML reports accumulate without producing any security decision. Changes to suppliers or systems can introduce new authentication failures without anyone noticing.
What to do: give report ownership to a named person or team, use appropriate analysis tooling, and review trends regularly. Email authentication is an ongoing control, not a one-off DNS task.
6. Subdomains have been forgotten
What it means: the organisation concentrates on its main domain while subdomains remain weakly protected, unused or available for abuse.
What to do: review which subdomains send mail, publish explicit SPF policies where appropriate, and use the DMARC sp tag where a separate subdomain policy is required. Domains and subdomains that never send email should also be considered in the wider anti-spoofing design.
Why a "pass" does not always mean secure
Automated checkers are valuable because they reveal what your DNS currently publishes. They cannot, on their own, confirm that every authorised service genuinely needs to send email, that an attacker has not obtained access to an authorised platform, that SPF and DKIM remain aligned across every message stream, that DMARC reports are being reviewed, that a monitoring policy is ready to move to enforcement, or that the wider domain and email environment is securely configured.
This is the distinction between checking for a record and assessing whether the control works.
A practical remediation process
For most organisations, the safest sequence is:
- Discover: list domains, subdomains and every legitimate email sender
- Check: inspect SPF, DKIM and DMARC records and validate their syntax
- Monitor: collect DMARC aggregate reports and classify sending sources
- Correct: fix missing authorisations, alignment problems and obsolete services
- Test: confirm that important transactional and business messages authenticate correctly
- Enforce: move towards
p=quarantineandp=rejectwhen legitimate mail is consistently aligned - Maintain: review reports and repeat the assessment whenever email suppliers or infrastructure change
Do not treat the process as a race to achieve a green result in a checking tool. The objective is to make domain impersonation harder without disrupting genuine communication.
Use Wuluf's free Domain Security Check to inspect your domain's live SPF and DMARC configuration. If it identifies missing records, policy gaps, or an environment that has become difficult to untangle, Wuluf can assess the wider configuration, identify legitimate sending systems, and help you move towards effective enforcement.
If you're unsure whether your current setup would hold up under scrutiny — or want an independent view of your wider email and domain security — get in touch with the Wuluf team.
Frequently asked questions
Can I have more than one SPF record?
No. A domain should publish one SPF policy. If several services send email for the domain, their authorised mechanisms must be combined into a single valid record.
Does SPF stop email spoofing?
SPF helps receiving systems check whether a sending server is authorised to use a domain in the SMTP transaction. It does not protect every identity visible in an email and can be affected by forwarding. DMARC combines authentication with alignment to protect the domain shown in the From address more directly.
Does DMARC require both SPF and DKIM to pass?
No. A message can pass DMARC when either SPF or DKIM passes and the successful identity aligns with the visible From domain. In practice, configuring and monitoring both provides stronger resilience.
Should every organisation use p=reject?
Reject is generally the strongest DMARC policy, but it should be introduced after legitimate sending services have been discovered, aligned and tested. Moving too quickly can cause genuine email to be rejected.
How long do DNS changes take to appear?
It depends on the record's time to live, your DNS provider and caching resolvers. Some changes appear quickly; others can take longer to propagate. Check the authoritative record as well as external lookup results before assuming a change has failed.
How often should SPF and DMARC be checked?
Check them after any change to email providers or sending services, and review DMARC reporting continuously. A periodic formal review is also sensible, because forgotten suppliers and legacy records commonly accumulate over time.