Could someone send email that looks like it came from your company?

The name shown in an email is not proof that your company authorized it. Email authentication gives receiving systems additional information to evaluate, but its configuration depends on the domain and sending service. Some providers configure parts of it for you; other settings require action by the domain administrator. Checking the current arrangement is more useful than assuming that a feature is enabled or absent.

Which means the honest answer to the question in the title is: a short check can reveal useful information, but it is not a complete impersonation-risk assessment. Our training walkthrough shows a free check requiring no account. This article explains what the three records do, so the result means something when you see it.

Distinguish the addresses involved

Start with the mechanics. When a message is delivered, there are two different sender addresses in play.

The envelope sender is used at the protocol level between mail servers, and it is where bounces are returned. The header From is the address your recipient sees in their inbox. There is no requirement that these match, and legitimate services routinely make them different — a marketing platform sending on your behalf will typically use its own envelope address while displaying yours.

That flexibility is useful and it is also the gap. Anything that authenticates only the envelope sender is not, on its own, telling recipients anything about the name they are reading.

SPF: which servers may send

An SPF record is a DNS entry listing the servers and services authorized to send mail for a domain. A receiving system looks it up and checks whether the connecting server appears on the list.

The essential caveat is the one above: SPF is evaluated against the envelope sender domain. A pass tells you the sending server was authorized for that domain. It does not by itself establish anything about the From address a person reads.

SPF also breaks in an ordinary and legitimate way. Forwarding or mailing-list handling can change the delivery path and cause an SPF failure, depending on how the intermediary handles the envelope address. A failure in that situation does not establish dishonest intent. This is a normal characteristic of the mechanism, not evidence of an attack.

DKIM: a signature over the message

DKIM adds a cryptographic signature, applied by the sending system, using a key whose public half is published in DNS. The receiver verifies the signature and learns that the signed parts of the message have not been altered in transit and that the signing domain vouched for it.

A DKIM signature can remain valid through forwarding if the relevant signed content is preserved. Changes to signed content can affect verification. It also, on its own, says nothing about whether the signing domain matches the domain in the From line. A message can carry a perfectly valid signature from a domain the recipient has never heard of.

DMARC: tying it back to what the reader sees

DMARC is the piece that connects authentication to the visible From domain. It requires alignment: the domain that passed SPF, or the domain that signed with DKIM, must line up with the domain in the From header.

Two points are useful when interpreting a result.

DMARC is satisfied by an aligned SPF pass or an aligned DKIM signature. It does not require both. A message that fails SPF because it was forwarded can still pass DMARC on an aligned DKIM signature, which is exactly the resilience the design intends.

And a DMARC record carries a policy telling receivers what to do with messages that fail. A policy of p=none does not request quarantine or rejection on the basis of DMARC failure. Reporting requires the appropriate reporting destinations and configuration; p=none alone does not arrange it. A monitoring stage can help you understand legitimate sending before deciding whether and how to change enforcement.

What the free check tells you

The walkthrough shows how to look these up for your own domain without an account. What you will learn is whether an SPF record exists and what it lists, whether a DMARC record exists and what policy it declares, and — with a little more work, since DKIM lookups need the selector name your provider uses — whether a DKIM public-key record is published for that selector. A published key alone does not confirm that a service is signing outgoing messages correctly.

That is a genuinely useful picture, and it is a snapshot of published configuration rather than a test of every message you send. It will not tell you whether a particular third-party service is signing correctly, and it will not tell you what receiving systems are actually doing with your mail. Configured DMARC aggregate reports and testing of representative messages can provide further evidence. Reporting depends on receiving-system participation and does not necessarily cover every message.

A realistic order of work

• Run the check and record what exists today.
• Inventory every system that sends mail as your domain: your mail platform, invoicing, CRM, marketing tools, website forms, appointment reminders, anything bought by a department for a campaign.
• Publish or correct SPF so it accurately reflects that inventory, and keep it within the lookup limits your provider documents.
• Enable DKIM signing at your mail platform and at every significant third-party sender.
• Publish DMARC with reporting enabled, starting at monitoring.
• Read the reports for a period long enough to include monthly and quarterly senders.
• Only then tighten the policy, in stages, watching for legitimate mail you had forgotten about.

An inventory helps you identify a less obvious sender, such as an appointment system, before a policy change affects its messages. Keep the record current when a department adds or retires a service.

What this does not achieve

Correct records do not guarantee delivery. Reputation, content and recipient filtering all still apply, and no configuration entitles your mail to reach an inbox.

Authentication also does not mean a message is honest. Mail from a compromised legitimate account may pass authentication while carrying a fraudulent request. A lookalike domain may also authenticate successfully for its own domain. Neither is addressed by anything on your own domain.

And a failure at the receiving end is not proof of forgery. Forwarding and misconfiguration produce failures every day.

These mechanisms help receivers evaluate use of your exact domain. Properly configured reporting can show patterns that need investigation, but it does not identify an individual sender’s intent or guarantee comprehensive visibility.

Your next step

Watch the walkthrough and run the check on your domain today, then start the sender inventory — it gives the next technical decisions useful context.

If you would like help working through it, ALCO USA Inc does 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
Google on checking whether a message was authenticated: https://support.google.com/mail/answer/180707?hl=en

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