Start DMARC with reporting, identify every legitimate sender and tighten policy only after SPF and DKIM alignment are reliable.
Applies to: Email authentication and DNS security
SPF, DKIM, DMARC, DNSSEC and CAA solve different problems. Deploy them deliberately, validate syntax before tightening policy and keep an emergency rollback record for every production DNS change.
Before you start
- Publish one valid SPF policy and enable DKIM for each legitimate sending platform.
- Choose a mailbox or reporting service able to process aggregate reports.
Step-by-step
- Publish a DMARC record at _dmarc.example.com with p=none and an aggregate reporting address.
- Collect reports for long enough to cover normal newsletters, applications, support systems and infrequent senders.
- Classify each source and fix SPF or DKIM alignment. A sender merely passing SPF for another domain does not satisfy DMARC alignment.
- Remove unauthorised or obsolete senders and document the remaining approved services.
- Move gradually to quarantine, optionally using pct to limit enforcement while monitoring failures.
- Move to reject only when legitimate traffic consistently aligns and responsible staff can monitor reports and user complaints.
- Review subdomain policy, forwarding behaviour and third-party changes regularly.
Confirm the result
- Legitimate mail passes aligned SPF or DKIM and unauthorised spoofing is increasingly quarantined or rejected.
Common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| Legitimate forwarded mail fails SPF. | Forwarding changes the connecting server and can break SPF. | Ensure DKIM survives forwarding or use a provider that supports appropriate forwarding standards; do not weaken DMARC without reviewing reports. |
| Reports show an unknown sender. | It may be abuse, an old service or an application not included in the inventory. | Identify the owner before authorising it; do not add unknown infrastructure to SPF merely to remove a report failure. |
Important notes
- A DMARC reject policy can block legitimate mail when deployed before all senders are known. Keep a tested rollback value.
When to contact Tudor Internet
Open a ticket through the Customer Portal when the checks above do not resolve the issue, when an action is unavailable for your service, or when continuing could risk data loss or service interruption. Include the following so the request can be investigated efficiently:
- The full domain name
- The current and intended registrar or nameservers
- Any registry or transfer error shown
- Whether website or email service is currently live
Do not send passwords, private keys, full payment-card details, one-time authentication codes or unredacted identity documents in an ordinary support reply.
Related articles
- Set up SPF, DKIM and DMARC records
- Create and troubleshoot TXT records
- Use CAA records without blocking certificate renewal
- DNSSEC availability and changes
Last reviewed: 2026-07-18.
