Email provider reports domain spoofing: check SPF, DKIM, and DMARC

TL;DR — If your email provider says your domain is being spoofed, the most common cause is missing or incomplete DNS email authentication: SPF (which servers may send mail), DKIM (a cryptographic signature on mail), and DMARC (a policy telling receivers what to do when checks fail). Start by checking your DNS records in your DNS provider's dashboard and compare them to the records your real mail provider tells you to publish; in many cases, adding or correcting SPF, DKIM, and DMARC stops the warning and reduces abuse. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and you get an alert from your email provider saying messages "from your domain" are failing authentication or appear to be spoofed. At the same time, a few customers reply asking why they received odd invoices or password reset emails that you did not send. Your website is fine, your team can still send some email, and that makes it more confusing: this is not a full outage, it is a trust problem. You need to work out whether the bad mail is actually coming from your systems, or whether attackers are just forging your domain in the From address.

Symptoms

• Your email provider shows warnings like:

Potential domain spoofing detected for example.com

• Security reports mention authentication failures such as:

SPF fail for example.com
DKIM=none
DMARC policy not found
DMARC fail: p=none or no alignment

• Recipients report suspicious messages that look like they came from you, often with your domain in the visible From address.
• Your legitimate mail lands in spam or is rejected with messages like:

550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy

• Message headers on a suspicious email show results like:

Authentication-Results: spf=fail smtp.mailfrom=example.com; dkim=none; dmarc=fail header.from=example.com

• You have recently changed email providers, DNS providers, or added a new app that sends email on your behalf.

Likely causes

Step-by-step diagnosis

1. Check whether DMARC exists.
   • Dashboard path: your DNS provider's dashboard → DNS/Zone/Records → search for _dmarc.
   • CLI option if you prefer:

dig +short TXT _dmarc.example.com

• This is your problem if you get no result, or the record does not start with v=DMARC1;.
• Jump to: Fixes → ### DMARC record missing or too weak to help.

1. Check SPF at the root of the domain.
   • Dashboard path: DNS/Records → search for TXT records named @ or your bare domain.
   • CLI option:

dig +short TXT example.com

• This is your problem if there is no v=spf1 ... record, or there are two different SPF TXT records, or the record does not include your real sending service.
• Jump to: Fixes → ### SPF record missing, wrong, or has multiple SPF TXT records.

1. Check DKIM status in the mail provider.
   • Dashboard path: in your mail provider's admin area, open the domain or sender authentication page; look for DKIM status.
   • If the provider gives you a selector (the DKIM record name prefix), you can also check DNS directly:

dig +short TXT selector1._domainkey.example.com

• This is your problem if DKIM shows "not configured", "pending", "failed", or the DNS lookup returns nothing.
• Jump to: Fixes → ### DKIM not enabled or DNS DKIM record missing.

1. Inspect one suspicious message to find the actual sending path.
   • In your mail app, open the suspicious message and choose "View source", "Show original", or "View headers".
   • Look for lines like:

Return-Path: <bounce@mailer.thirdparty.example>
Authentication-Results: spf=fail; dkim=none; dmarc=fail
Received: from mail.some-service.com

• This is your problem if the message came from a service you use for invoices, CRM, forms, newsletters, or support, but that service is not included in SPF or DKIM.
• Jump to: Fixes → ### A third-party app is sending mail but is not included in SPF/DKIM.

1. Compare DNS records against your current mail provider's setup page.

   • Dashboard path: open your current mail provider's domain setup/authentication page in one tab, and your DNS provider's records page in another.
   • This is your problem if the provider expects different MX/TXT/CNAME values than the ones currently published, especially after a migration.
   • Jump to: Fixes → ### DNS points to the wrong provider after a migration.

2. Check for account compromise if the messages were truly sent through your provider.

   • Dashboard path: your mail provider's admin/security area → recent sign-ins, audit log, or sent mail activity.
   • This is your problem if you see logins from unknown locations, app passwords you do not recognize, or large volumes of sent mail from a real mailbox.
   • Jump to: Fixes → ### One of your real mailboxes or SMTP credentials is compromised.

[Recipients] <---- suspicious mail ---- [Internet]
      ^
      | 1. headers show SPF/DKIM/DMARC results
      |
[Your DNS] ---- 2. publish auth records ----> [Mail Receivers]
      |
      | 3. records authorize
      v
[Your Mail Provider] ---- 4. signs/sends ----> [Internet]

Fixes

SPF record missing, wrong, or has multiple SPF TXT records

SPF says which servers are allowed to send mail for your domain.

• In your DNS provider's dashboard, keep exactly one SPF TXT record for the root domain.
• Remove extra v=spf1 TXT records; SPF must be combined into one record.
• Publish the value your real mail providers require. A common pattern looks like:

Type: TXT
Name: @
Value: v=spf1 include:_spf.your-mail-provider.example include:spf.third-party-app.example ~all

• If you are replacing two SPF records, merge them into one line instead of keeping both.

CLI check:

dig +short TXT example.com

Verify it worked: the output shows exactly one SPF TXT record and it includes every service that sends mail for you.

DKIM not enabled or DNS DKIM record missing

DKIM adds a signature that receivers can verify against a DNS record.

• In your mail provider's admin dashboard, open domain authentication and enable DKIM for your domain.
• Copy the exact DNS record name and value the provider gives you. Many providers use either a TXT record or a CNAME record.
• Add it in your DNS provider's dashboard. Example TXT-style DKIM record:

Type: TXT
Name: selector1._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

• Example CNAME-style DKIM record:

Type: CNAME
Name: selector1._domainkey
Value: selector1-example-com._domainkey.mailprovider.example

• Return to the mail provider dashboard and click the verify/recheck button if it has one.

CLI check:

dig +short TXT selector1._domainkey.example.com

Verify it worked: the provider shows DKIM as verified, or the DNS query returns the expected DKIM value.

DMARC record missing or too weak to help

DMARC tells receiving mail systems what to do when SPF and DKIM fail, and where to send reports.

• In your DNS provider's dashboard, add a TXT record named _dmarc.
• Start with a monitoring policy if you are unsure, then tighten it after reviewing reports.

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

• If you already know all legitimate senders are covered, move to quarantine:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

⚠️ A strict DMARC policy can cause real mail to go to spam or be rejected if SPF/DKIM are not fully set up for every sending service. Publish p=none first if you are still inventorying senders.

CLI check:

dig +short TXT _dmarc.example.com

Verify it worked: the lookup returns one valid DMARC record, and later message headers show dmarc=pass for legitimate mail.

A third-party app is sending mail but is not included in SPF/DKIM

This is common with CRMs, support tools, form plugins, invoicing systems, and marketing platforms.

• Find the service name from the message headers or the app's email settings page.
• In that app, open its domain authentication/sending domain page and copy its SPF include and DKIM records.
• Add the app's SPF include to your single SPF record, for example:

v=spf1 include:_spf.your-mail-provider.example include:spf.crm-sender.example ~all

• Add the DKIM record the app gives you, usually under selector._domainkey.
• If the app supports using a subdomain for sending, prefer that for isolation, for example mail.example.com instead of your root domain.

Verify it worked: a new message from that app shows spf=pass or dkim=pass, and ideally dmarc=pass in the original headers.

DNS points to the wrong provider after a migration

This happens when DNS still contains records from an old mail provider.

• Open your current mail provider's setup page and copy the exact MX, SPF, DKIM, and any required CNAME records.
• In your DNS provider's dashboard, replace old values with the current provider's values.
• Remove stale DKIM selectors and old SPF includes that no longer belong to any active sender.
• Wait for DNS propagation; many providers update within minutes, but allow up to the record TTL (cache lifetime).

CLI checks:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Verify it worked: DNS answers match your current provider's setup page exactly.

One of your real mailboxes or SMTP credentials is compromised

If the bad mail was actually sent through your real provider, DNS alone will not fix it.

⚠️ Resetting passwords, revoking app passwords, or disabling SMTP can interrupt legitimate mail sending for staff and apps. Do this in a planned order and tell your team first.

• In your mail provider's admin/security dashboard, sign out suspicious sessions.
• Reset the affected mailbox password.
• Revoke app passwords, API keys, and SMTP credentials you do not recognize.
• Turn on MFA (multi-factor authentication) for the affected account and all admin accounts.
• If an app was using compromised SMTP credentials, create new credentials and update that app's settings.

Verify it worked: suspicious sign-ins stop, outbound spam volume drops, and no new unauthorized messages appear in sent mail or audit logs.

Prevention

• Publish and monitor DMARC reports to a real mailbox or reporting service:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

• Keep a sender inventory in one place. List every service that sends as your domain: staff mail, website forms, CRM, support desk, invoices, newsletters. Update SPF/DKIM whenever you add one.
• Add a quarterly DNS review task: compare live records with your current mail provider's setup page using:

dig +short MX example.com && dig +short TXT example.com && dig +short TXT _dmarc.example.com

• Use a dedicated subdomain for bulk or app-generated mail, for example notify.example.com, so marketing and transactional mail do not share the same identity.
• Turn on MFA for all mail admins and remove unused SMTP credentials. If your provider supports it, disable basic SMTP auth for user mailboxes and use provider-managed API sending for apps instead.
• After any provider migration, add a checklist item in your change process: verify MX, SPF, DKIM, and DMARC before closing the change.

{
  "mail_dns_check": [
    "MX matches current provider",
    "one SPF record only",
    "DKIM verified for each sender",
    "_dmarc record present"
  ]
}

This article was written by an AI system and published pending human review. Verify anything you intend to act on.