Would you know where to check your domain's email protections?

AI summary

ALCO USA Inc provides guidance on verifying domain email security configurations, specifically SPF, DKIM, and DMARC. The process involves documenting all business domains and systems that send email, running a check on these domains, and evaluating the results against four common configuration scenarios to ensure proper authentication.

Users are encouraged to maintain a comprehensive list of all domains owned by their business and every system authorized to send email on their behalf.
The domain verification check identifies the current status of email security records but does not guarantee protection against all threats like compromised accounts or lookalike domains.
A DMARC policy of p=none is a monitoring stage and should not be considered a completed security posture.
Proper email authentication maintenance requires periodic review of sender inventories and report analysis, particularly when adopting new systems or tools.
ALCO USA Inc offers professional assistance with these email security configurations as part of their managed hosting and IT support services.

Updated Sep 9, 2026 · 11:18 am MDT

Adam Leveille CEO & Principal Consultant

25 February 2026 6 min read

This one is meant to be done rather than read. Our walkthrough, "Can Strangers Send Email As Your Company?", shows a check you can run yourself in a couple of minutes, without an account and without spending anything. All you need is your domain name — the part after the @ in your work email address.

What follows is the companion: what to do with each of the four results you are likely to get. These four examples are not exhaustive. A lookup may show an invalid record, an error, or a configuration that needs more detailed review. Record the result rather than changing DNS based on a label alone.

Before you start

Write down two things.

First, your domain, exactly as it appears in your email address. If your business uses more than one — an old brand, a regional variant, a domain used only for marketing — list them all. Domains you do not send from still deserve records, because "we never use it" is not visible to anyone receiving mail that claims to come from it.

Second, a rough list of every system that sends email as you. Your mail platform. Your invoicing or accounting system. Any marketing or newsletter tool. Your CRM. Contact forms on the website. Appointment or delivery notifications. Anything a department signed up for independently. The list gives the administrator context for evaluating the configuration. Ask the relevant departments to review it, including services that send only occasionally.

Then run the check as the walkthrough shows.

Result one: no SPF record and no DMARC record

Confirm the result and the exact domain being checked. Absence of a record does not tell you how every sender or subdomain is configured, so first identify who is responsible for the domain and mail services.

Ask the responsible administrator to compare the sender inventory with each provider’s setup instructions. That review may lead to publishing SPF, enabling DKIM for relevant services, and configuring DMARC with an appropriate reporting destination. The order and details should reflect the existing mail arrangement. Avoid copying another business’s DNS records or making changes without the necessary authorization.

Do not attempt to reach a strict enforcement policy in one afternoon. The value of the monitoring stage is that it shows you the senders your inventory missed, and the first inventory may not include every sending service.

Result two: SPF exists, DMARC does not

An SPF record alone does not establish whether the visible From domain is authenticated for the messages your business sends.

SPF is evaluated against the envelope sender, the address used between mail servers, rather than the From address your recipient reads. Without DMARC, nothing requires those two to have anything to do with each other, so a message can pass SPF while displaying your company in the From line and originating somewhere unrelated.

The work here is to confirm the SPF record actually matches your current sender list — records go stale as tools are added and dropped — enable DKIM signing, and then publish DMARC at monitoring.

Result three: DMARC exists with p=none

Better, and frequently misunderstood as finished.

A policy of p=none does not request quarantine or rejection because of a DMARC failure. Reports require configured reporting destinations and receiving-system participation. Check both the policy and the reporting setup before assuming monitoring is active.

Two questions matter here. Are the reports going somewhere a person or a service actually reviews? And how long has this been in place? If the policy has been in place for some time, ask what has been learned from it and whether a review is due. The age of the record alone does not tell you whether it is effective or appropriate.

The path forward is to review representative reports and test occasional senders, including monthly or quarterly workflows where relevant, correct anything legitimate that is failing, then tighten in stages while watching for fallout.

Result four: DMARC with quarantine or reject

The published policy requests stronger handling of failing messages. That is still a configuration fact, rather than proof that all wanted mail is authenticated or that all unwanted mail will be blocked.

Check whether the policy applies to subdomains as well, and whether the current subdomain arrangement matches your sending needs. Check that reports are still being reviewed, because a new sender may need configuration changes before its messages pass the intended checks. And re-run the sender inventory whenever a department adopts a new system — this configuration needs maintenance, not just a launch.

Also confirm DKIM is genuinely in place rather than relying on SPF alone. DMARC is satisfied by an aligned SPF pass or an aligned DKIM signature, and a DKIM signature may remain valid through forwarding when the signed content is preserved. Forwarding can affect SPF depending on envelope handling; representative tests help identify the behavior in your actual mail flow.

Your follow-along checklist

List every domain your business owns or sends from.
List every system that sends mail as you.
Run the check on each domain and write down what exists today.
Correct SPF to match reality, and keep within the lookup limits your provider documents.
Enable DKIM at your mail platform and at each significant third-party sender.
For a new rollout, have the authorized administrator choose an appropriate initial policy and reporting setup. Preserve existing enforcement settings pending review; do not downgrade a working policy by following this checklist.
Review representative sending cycles and test occasional senders before deciding on an enforcement change.
Tighten in stages, and re-check after every new tool is adopted.

What the check does not tell you

It reads published configuration at a moment in time. It does not test every message you send, does not confirm a particular third-party service is signing correctly, and does not tell you what receiving systems are doing with your mail in practice. Configured reports can add evidence, along with representative message tests. They depend on receiver participation and do not necessarily provide a complete view of every message.

It also cannot protect you from everything. Mail from a lookalike domain may pass authentication for that domain. Mail from a compromised legitimate account may also pass while carrying a harmful request. And correct records never guarantee delivery — filtering, reputation and content still apply.

Your next step

Watch the walkthrough with your domain name in front of you and run the check now, and write down the result for review. Then start the sender inventory, because that is the part that takes real time.

If you would rather work through it with someone who has done it before, ALCO USA Inc handles this alongside managed hosting, development and IT support.

Sources and further reading

ALCO training on email spoofing: https://alcohq.com/training/email-spoofing
Video walkthrough: https://youtu.be/ueK8L2fFGv0
Google on preventing spoofing with SPF, DKIM and DMARC: https://support.google.com/mail/answer/81126?hl=en-GB

RFC7489, DMARC policy and alignment: https://www.rfc-editor.org/rfc/rfc7489
RFC7208, SPF: https://www.rfc-editor.org/rfc/rfc7208
RFC6376, DKIM: https://www.rfc-editor.org/rfc/rfc6376

More from ALCO

6 September 2026

Before you open a support ticket, start here

A quick status check can add useful context to a support request. Here is what to look for and how to describe a problem

ALCO has joined the Caldwell Chamber of Commerce

ALCO USA Inc is pleased to join the Caldwell Chamber of Commerce. We look forward to getting to know fellow members and

Designing monitoring that earns its alerts

Most monitoring degrades into noise within a year. A full account of how we decide what wakes a person, what raises a ti

Apply this to your business

Talk with ALCO about your systems and the next practical step for your organization.

Contact ALCO