DigitalBanzai Knowledge

Email Security

Practical guide to what the scanner currently checks for SPF and DMARC, when the finding really matters, and how to correct the domain DNS records safely.

Italian version
Severity
Moderate
Estimated fix time
10-30 min
Technical level
Beginner / Intermediate
Applies to
DNSEmail hostingWordPressCMS / E-commerce

Quick Answer

the check reviews whether the analyzed domain publishes SPF and DMARC records in DNS. These records help reduce the risk of unauthorized email being sent while using the domain as the apparent sender. Their presence is a good basic signal, but it does not by itself mean the email setup is complete or fully correct.

What it is

The Email Security check in the report currently focuses on two public DNS records tied to email authentication for the domain:

  • SPF states which servers are authorized to send email on behalf of the domain.
  • DMARC defines how receiving mail servers should handle messages that do not pass the expected authentication checks.

These records are not part of the website code. They belong to the domain DNS configuration. They matter especially when the domain is used for contact email, website forms, newsletters, CRM workflows, ecommerce notifications, or automated outbound messages.

Why it matters

A domain without SPF or DMARC is more exposed to misuse in email.

This does not automatically mean the site has been compromised or that someone is already abusing the domain. It does mean that some public instructions are missing, and those instructions help email providers distinguish legitimate messages from suspicious ones more clearly.

For a business, professional, or organization website, these records matter because they help:

  • protect the domain's reputation;
  • reduce the risk of apparent-sender spoofing;
  • give mail providers a basic policy for handling unauthenticated or misaligned messages.

Info: having SPF and DMARC does not by itself guarantee perfect deliverability, and it does not replace a broader review of every system that sends email for the domain.

How this is checked

the check reviews whether the domain publishes in DNS:

  • an SPF record;
  • a DMARC record.

When those records are present, the check can show a positive result such as:

SPF configured correctly
DMARC configured correctly

In the technical details, the scanner may also show the detected SPF record value and the detected DMARC record value.

The current check is intentionally focused. Today it does not measure real email deliverability, it does not send test messages, and it does not confirm that every legitimate sending service is fully aligned with the detected records.

Technical note: the Email Security check should be kept separate from Email Service Indicators. That other check highlights observable signals associated with email services on the domain, but it does not replace the specific SPF and DMARC review.

Possible findings

Each finding stands on its own, so you can jump straight to the one shown in your report.

SPF present and DMARC present

Severity: Informational / Moderate

The domain publishes both records. This is a good basic signal: the report found both SPF and DMARC and may show their values in the technical details.

SPF missing

Severity: Moderate

The record that declares which servers may send email for the domain is missing. If the domain sends email, it is worth fixing.

DMARC missing

Severity: Moderate

A public policy telling receiving providers how to handle unauthenticated or misaligned messages is missing. This should usually be reviewed and planned for correction.

SPF and DMARC both missing

Severity: High

The domain publishes neither of the two basic records currently checked by the scanner. For a domain used in business or operational communication, this is a higher-priority signal to review.

Tip: if the domain does not send email at all, urgency may be lower. If it sends newsletters, quotes, confirmations, notifications, or operational communication, the priority rises quickly.

Priority depends on how the domain is used for email:

  1. If SPF or DMARC is missing and the domain sends email: identify which services send mail for the domain and plan the DNS update promptly.
  2. If the records are present: still review the record values to confirm that they really match the services in use.
  3. If you are not sure which systems send email: make that inventory first, then update the DNS.

How to fix it

The correction happens in the domain DNS, not in the website code.

1. What to check before editing DNS

Before changing SPF or DMARC, it is important to know which services send email for the domain. Common examples include:

  • the hosting provider;
  • an SMTP server;
  • Google Workspace;
  • Microsoft 365;
  • newsletter platforms;
  • CRM systems;
  • WordPress plugins that send email;
  • billing, booking, or automation services.

An SPF record that is too restrictive or incomplete can cause delivery problems. That is why it is better to list the real sending services first.

2. SPF example

An SPF record often looks like this:

v=spf1 include:spf.example.com ip4:192.0.2.10 -all

The real value depends on the service sending email: hosting, SMTP provider, Google Workspace, Microsoft 365, newsletter tools, CRM systems, or other platforms.

3. DMARC example

A DMARC record often looks like this:

v=DMARC1; p=none; rua=mailto:report@example.com

The p=none policy is often used as a starting point because it allows monitoring without immediately blocking mail. More restrictive policies such as quarantine or reject should only be applied after verifying that all legitimate sending systems are configured correctly.

4. WordPress

On WordPress, many sites send email through plugins: contact forms, WooCommerce, booking systems, membership areas, newsletters, or automatic notifications.

In those cases, checking WordPress alone is not enough. You need to identify which service is actually sending the email.

  • If the site uses the hosting provider for mail, SPF must include that provider.
  • If it uses an external SMTP service, SPF must include that service.
  • If it uses newsletter or CRM platforms, those services also need to be authorized.

DMARC should be configured carefully, especially when the domain sends email through multiple tools.

5. Static sites

A static site can still rely on email.

Even without a backend, the site may contain mailto: links, forms handled by third-party services, newsletters, or automations linked to the domain. In those cases, SPF and DMARC still matter because they apply to the email domain, not to the site-generation technology.

How it appears in the report

In the report, the Email Security check shows a simple summary and a technical block with the detected records.

Example interface:

Email Security
SPF configured correctly
DMARC configured correctly

Example of technical details observable today:

{
  "url": "https://example.com",
  "domain": "example.com",
  "spf": {
    "enabled": true,
    "record": "v=spf1 include:spf.example.com ip4:192.0.2.10 -all"
  },
  "dmarc": {
    "enabled": true,
    "record": "v=DMARC1; p=none; rua=mailto:report@example.com"
  },
  "status_code": 200,
  "final_url": "https://www.example.com/"
}

This means that the scanner, today, may expose mainly:

  • whether SPF is present or missing;
  • whether DMARC is present or missing;
  • the detected SPF record value;
  • the detected DMARC record value;
  • the observed domain and final URL.