When you send an email, how does the recipient’s mail provider know it genuinely came from your organisation? Email addresses are easy to imitate, so modern mail systems use several checks to distinguish legitimate messages from forged ones.
SPF, DKIM, DMARC and PTR each perform a different job. Together they help receiving servers assess who sent the message, whether it was authenticated, and how it should be handled.
SPF authorises sending infrastructure. DKIM validates a cryptographic signature. DMARC checks alignment with the visible From domain and specifies a policy. PTR identifies the sending server through reverse DNS.
The four checks at a glance
1. SPF: Sender Policy Framework
SPF is a DNS TXT record that identifies which mail systems may send messages using a domain in the SMTP envelope sender (also known as the Return-Path). The receiving server compares the connecting IP address with the domain’s SPF policy.
For a domain whose only outbound email service is Microsoft 365, a typical SPF record looks like this:
v=spf1 include:spf.protection.outlook.com -all
The include mechanism authorises the specified Microsoft 365 sending infrastructure. The -all mechanism says other senders should fail SPF. If the business also uses a CRM, marketing service or other mail gateway, its outbound email needs to be considered before adopting this example.
What if your website or cloud server also sends email?
A business might use Microsoft 365 for staff mailboxes while its website sends contact-form notifications, password resets, order confirmations or other automated messages. If a Webcore Panel hosting node or a dedicated cloud server delivers those messages directly using the business domain as its envelope sender, that sending infrastructure must also be authorised by SPF.
Webcore maintains the spf.webcore.cloud SPF include for authorised outbound mail across its infrastructure. Where the website or server sends through infrastructure covered by that policy, a domain using both Microsoft 365 and Webcore outbound mail can use a combined SPF record like this:
v=spf1 include:spf.protection.outlook.com include:spf.webcore.cloud -all
A dedicated server with its own public sending IP may instead need an explicit ip4: or ip6: mechanism, or its own authorised relay. If website mail is submitted through Microsoft 365 or another SMTP relay, authorise the service that actually delivers the message to recipient servers; you do not automatically need to add the website’s IP address.
Keep all authorised senders in one SPF TXT record for the domain rather than publishing separate SPF records. Check SPF’s ten-DNS-lookup limit and ensure DKIM or SPF aligns with the visible From address for DMARC. In particular, adding a server to SPF does not by itself guarantee a DMARC pass when that server uses a different envelope sender domain.
Important limitation: SPF authenticates the envelope sender domain, not necessarily the From address shown in an email client. Forwarding can also break SPF because the forwarding server’s IP address may not be authorised by the original sender’s SPF record.
2. DKIM: DomainKeys Identified Mail
DKIM attaches a cryptographic signature to outgoing mail. The sending service signs selected message headers and a body hash using a private key, while a corresponding public key is published in DNS under a selector-specific ._domainkey name.
The receiving mail system retrieves that public key and verifies the signature. A successful check means the signed portions have not been changed in ways that invalidate the signature and the sending service possessed the associated private key.
DKIM is useful for forwarded mail because the signature can remain valid when the message passes through another server, as long as the relevant signed content is preserved. However, a valid DKIM signature alone does not prove that the signing domain matches the address displayed in From. DMARC performs that alignment check.
For Microsoft 365, the domain administrator normally publishes two Microsoft-provided DKIM CNAME records in DNS and enables DKIM signing in Microsoft 365. The actual CNAME targets are tenant-specific and should not be guessed.
3. DMARC: Domain-based Message Authentication, Reporting and Conformance
DMARC builds on SPF and DKIM. It checks whether at least one authentication method passes and aligns with the domain in the visible From address. Alignment uses relaxed organisational-domain matching by default; strict matching can be requested in the DMARC record.
A message passes DMARC when either SPF passes with an aligned envelope sender domain or DKIM passes with an aligned signing domain. Both do not need to pass, although configuring both provides resilience.
A monitoring-only DMARC TXT record at _dmarc.example.com might be:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The rua address receives aggregate XML reports from participating receivers. It should be a mailbox or reporting service equipped to handle them. If reports are sent to another domain, that destination generally needs to authorise external DMARC report delivery in DNS.
DMARC enforcement policies
p=none: collect evidence without requesting special handling of failures.p=quarantine: request that failing messages be treated as suspicious, commonly routed to spam.p=reject: request that failing messages be rejected.
Receiving services retain their own filtering decisions. Start with monitoring, identify legitimate senders and fix authentication alignment before progressing to quarantine or reject. Applying a strict policy prematurely can affect genuine mail from websites, ticketing platforms or third-party senders.
4. PTR: Pointer records and reverse DNS
Ordinary DNS looks up an IP address from a hostname, such as mail.example.com. A PTR record does the reverse: it maps an IP address back to a hostname.
For example, a sending IP of 192.0.2.10 might have reverse DNS pointing to mail.example.com, and the hostname should resolve forward to the same IP. These addresses are illustrative, not production configuration.
Many receiving providers check reverse DNS as part of assessing the connecting mail server. Missing or inconsistent PTR records can cause mail delivery issues. PTR does not authenticate the sender’s visible email domain and is not a substitute for SPF, DKIM or DMARC.
PTR records are generally controlled by the IP address owner or their provider, not by whoever manages the company’s ordinary domain DNS. Microsoft 365 and Google Workspace usually manage PTR for their own outbound servers.
How they work together when an email is delivered
Imagine sales@example.com sends a message through Microsoft 365 to a customer on Gmail:
- Connect: Gmail sees the sending server’s public IP address and may check its PTR and forward DNS identity.
- SPF: Gmail checks the IP address against the SPF policy of the envelope sender domain.
- DKIM: Gmail verifies the message’s DKIM signature against the public DNS key.
- DMARC: Gmail checks whether successful SPF or DKIM authentication aligns with
example.comin the visible From address and considers the published policy. - Delivery decision: Gmail also evaluates reputation, spam signals and local policy before deciding whether to accept, filter or reject the message.
Correct authentication supports deliverability but does not guarantee inbox placement. Attackers can also register lookalike domains or use compromised legitimate accounts, so authentication does not stop every phishing attempt.
Who manages the records?
Microsoft 365 or Google Workspace customers: the DNS administrator publishes SPF, the provider-specified DKIM records and DMARC. The mail administrator enables or verifies DKIM signing in the service. The email provider normally manages PTR for its own sending IPs.
Self-hosted mail systems: the operator configures signing and mail server identity, publishes SPF/DKIM/DMARC in domain DNS, and asks the IP provider to set the appropriate PTR record.
Third-party sending services: website notifications, invoicing, CRM and bulk mail systems may each require their own SPF and/or DKIM configuration. They must be reviewed for DMARC alignment, not simply added blindly to the SPF record.
Frequently asked questions
Do I need all four?
Most business domains should use SPF, DKIM and DMARC together. PTR is important on outgoing mail infrastructure, but managed email services generally handle it themselves.
Can my DNS provider set up DMARC if my email is hosted elsewhere?
Yes. DMARC is published entirely in your domain’s authoritative DNS. The email administrator may still need to enable DKIM or identify other outbound sending services.
Does DMARC stop incoming spam?
DMARC primarily protects your domain against direct impersonation in mail sent to others. Your incoming spam filter is a separate layer of protection.
Can an incorrect DMARC configuration reject genuine messages?
Yes. Enforce quarantine or reject only after checking mail streams and reviewing reports. Legitimate services that are not correctly aligned can fail DMARC.
Will these records guarantee inbox delivery?
No. Receivers also assess IP and domain reputation, content, sending behaviour and other factors.
How Webcore can help
Webcore can assist with SPF validation, publication of provider-supplied DKIM records, DMARC configuration and diagnosis of authentication or deliverability issues. Customers whose DNS is managed by Webcore do not have to move their Microsoft 365 or other email hosting to benefit from these protections.
For help with your domain’s email authentication, contact Webcore.