Domain Security (SPF, DMARC, DKIM)

Documentation Index

Fetch the complete documentation index at: https://docs.petrasecurity.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

The Domain Security scan checks the three DNS records that decide whether someone can send email pretending to be you: SPF, DMARC, and DKIM. It runs against every custom domain your tenant’s users send mail from, and flags anything misconfigured. Open it from a tenant page by clicking Domain Security. Each domain expands to show its SPF, DMARC, and DKIM results, the risk each state creates, and a link to the matching section below.

​

How to read your results

Each record gets one of three states:

• Configured (green): the record is in place and enforcing. No action needed.
• Weak (yellow): the record exists but does not fully protect you. Worth fixing.
• Missing (red): the record is absent or actively unsafe. Fix this first.

The three records do different jobs:

• SPF lists which mail servers are allowed to send for your domain.
• DKIM cryptographically signs your outbound mail so receivers can verify it was not forged or altered.
• DMARC ties SPF and DKIM to the visible From address and tells receiving servers what to do when a message fails. DMARC is the record that actually stops domain spoofing.

​

Am I at risk of domain spoofing?

Domain spoofing is when an attacker sends email with your exact domain in the From address (for example billing@yourcompany.com) to trick your staff, customers, or partners. It is the basis of business email compromise (BEC), invoice-redirection fraud, and CEO-fraud wire transfers. Whether you are exposed comes down almost entirely to DMARC enforcement:

• No DMARC, or DMARC p=none: you are spoofable today. Forged mail that fails authentication is still delivered to inboxes. This is high risk.
• DMARC p=quarantine: forged mail is sent to spam instead of the inbox. Largely protected.
• DMARC p=reject: forged mail is refused outright. This is the strongest protection.

SPF and DKIM matter because DMARC relies on them to recognize your legitimate mail. One SPF state is especially dangerous: +all (or a bare all) authorizes every server, so an attacker’s mail can pass SPF and DMARC as your domain and defeat even p=reject. A ?all, softfail (~all), or missing all weakens SPF on its own, but an enforced DMARC policy still blocks spoofing. To be fully protected you want all three configured: SPF ending in -all, DKIM signing your mail, and DMARC at p=reject.

---

​

SPF record missing

What this means. There is no SPF record on the domain, so receiving servers have no list of which mail servers are allowed to send as you. Your exposure. Any server on the internet can send mail using your domain in the envelope. Combined with a missing DMARC record, attackers can impersonate your domain in phishing, BEC, and invoice-fraud campaigns against your employees, customers, and vendors. Your legitimate mail is also more likely to land in spam, because receivers cannot verify your senders. How to fix.

1. List every service that sends mail as your domain (Microsoft 365, Google Workspace, your marketing or invoicing tools, your help desk).
2. In your DNS, add a TXT record on the root domain with value v=spf1 followed by an include: for each sender, ending in -all.
3. For Microsoft 365 the include is spf.protection.outlook.com, so the record is v=spf1 include:spf.protection.outlook.com -all. For Google Workspace use v=spf1 include:_spf.google.com -all.
4. Publish only one SPF record per domain. If you use multiple senders, combine them into a single record: v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all.
5. Rescan the domain to confirm it now reads as Configured.

​

SPF allows all senders

What this means. Your SPF record ends in +all, which authorizes every server on the internet to send mail as your domain. This is worse than having no SPF at all. Your exposure. Forged mail will pass SPF checks, and because DMARC can pass on SPF alone, spoofed messages can be delivered as fully authenticated mail from your domain. An attacker does not need to compromise anything; they simply send as you. How to fix.

1. In your DNS, open the TXT record that begins with v=spf1.
2. Change the trailing +all to -all (hard fail). The qualifier at the end controls enforcement, and -all tells receivers to reject anything not listed.
3. Confirm every legitimate sender is included before you switch, so you do not block your own mail.
4. Rescan the domain to confirm.

​

SPF set to neutral

What this means. Your SPF record ends in ?all (neutral), which tells receivers not to treat unlisted senders as a failure. In practice this gives you no protection. Your exposure. SPF provides no protection on its own, so if DMARC is not enforced your domain can be spoofed. If DMARC is set to p=quarantine or p=reject, spoofing is still blocked, but you are relying entirely on DMARC and lose SPF as a layer. How to fix.

1. In your DNS, open the TXT record that begins with v=spf1.
2. Change the trailing ?all to -all (hard fail).
3. Confirm every legitimate sender is included first, then publish.
4. Rescan the domain to confirm.

​

SPF has no all mechanism

What this means. Your SPF record exists but does not end with an all mechanism, so receivers have no instruction for mail coming from servers not listed in the record. Your exposure. Unlisted senders default to neutral, so SPF will not catch them on its own. If DMARC is not enforced this leaves you open to spoofing; with DMARC at p=quarantine or p=reject, spoofing is still blocked but you lose SPF as a layer. How to fix.

1. In your DNS, open the TXT record that begins with v=spf1.
2. Add -all to the very end of the record.
3. Confirm every legitimate sender is listed first, then publish.
4. Rescan the domain to confirm.

​

SPF multiple records

What this means. The domain publishes more than one SPF record (more than one TXT record starting with v=spf1). SPF allows only one. Your exposure. Receivers treat multiple SPF records as a permanent error (permerror) and ignore SPF entirely, so SPF provides no protection and your legitimate mail can fail authentication. How to fix.

1. In your DNS, find every TXT record that begins with v=spf1.
2. Merge them into a single record that lists all of your senders, ending in -all. For example: v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all.
3. Delete the extra SPF records so only one remains.
4. Rescan the domain to confirm.

---

​

DMARC record missing

What this means. There is no DMARC record, so receiving servers have no policy for what to do with mail that fails authentication for your domain. Your exposure. This is the single biggest spoofing risk. Without DMARC, mail that forges your exact domain in the From address is typically delivered straight to recipients. This is the foundation of CEO-fraud wire transfers, invoice-redirection scams, and credential-phishing aimed at your staff and customers. How to fix.

1. Make sure SPF (ending in -all) and DKIM are configured first, so DMARC has something to validate your legitimate mail against.
2. In your DNS, add a TXT record at _dmarc.yourdomain.com to start in monitor mode: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.
3. Review the aggregate (rua) reports for two to four weeks to confirm all of your legitimate senders pass.
4. Raise the policy to p=quarantine so forged mail goes to spam: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com.
5. Once you are confident, move to the strongest policy, p=reject.
6. Rescan the domain to confirm.

​

DMARC policy is none

What this means. Your DMARC record is set to p=none. This monitors and reports but does not enforce anything. Your exposure. Email that fails authentication and forges your domain is still delivered to recipients. p=none is a useful first step for collecting reports, but on its own it leaves your domain spoofable. How to fix.

1. Review your DMARC aggregate (rua) reports to confirm your legitimate senders are passing SPF or DKIM.
2. In your DNS, edit the TXT record at _dmarc.yourdomain.com and change p=none to p=quarantine.
3. Optionally roll out gradually with the pct tag (for example p=quarantine; pct=25), then increase to 100.
4. Once stable, move to p=reject for full protection.
5. Rescan the domain to confirm.

​

DMARC policy unreadable

What this means. A DMARC record is present, but its policy tag could not be read, so we cannot confirm that forged mail will be blocked. Your exposure. Enforcement is unverified. The record may be malformed or missing its policy tag, which can mean it provides no protection at all. How to fix.

1. In your DNS, open the TXT record at _dmarc.yourdomain.com.
2. Confirm it begins with v=DMARC1; and contains a valid policy tag of p=quarantine or p=reject.
3. Remove any typos, stray characters, or duplicate DMARC records (there should be exactly one).
4. Rescan the domain to confirm.

---

​

DKIM record missing

What this means. No DKIM record was found for the common selectors we check, so your outbound mail does not appear to be cryptographically signed. Your exposure. Receivers cannot confirm that a message genuinely came from you and was not altered in transit. DKIM also gives DMARC a second way to validate your legitimate mail, which matters when forwarding breaks SPF. Without it, your DMARC enforcement is weaker and your mail is more likely to be marked as spam. How to fix.

1. Enable DKIM with your mail provider:
   • Microsoft 365: in the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, select your domain, and enable signing. Microsoft gives you two CNAME records (selector1 and selector2) to publish in DNS.
   • Google Workspace: in the Admin console, go to Apps > Google Workspace > Gmail > Authenticate email, generate a key, and publish the provided TXT record at google._domainkey.yourdomain.com.
2. Publish the CNAME or TXT records your provider gives you in DNS.
3. Return to your provider and turn DKIM signing on.
4. Rescan the domain to confirm.