IronSights

Free tool

Email DNS Security Checker.

Check whether your domain has SPF, DKIM, and DMARC configured correctly. Get an instant security score and plain-English explanation of every finding.

Instant results

No waiting, no signup

Plain English findings

Not raw DNS output

SPF, DKIM and DMARC

All three protocols checked

Microsoft 365 aware

Checks M365 DKIM selectors

Why this matters

Gaps in email DNS make your domain easy to impersonate.

Without SPF, DKIM, and DMARC in place, attackers can send email that appears to come directly from your domain. Your staff, clients and suppliers see your name in the From field and have no way to tell it is not genuine.

These attacks do not require access to your systems. They exploit the absence of DNS records that instruct receiving mail servers on how to verify email from your domain.

Invoice fraud

Attackers send invoices from a spoofed version of your domain to your clients, redirecting payments to fraudulent accounts. Your business carries the reputational damage.

CEO impersonation

Criminals impersonate your executive team to instruct staff to make urgent payments or share credentials. Known as business email compromise, this cost Australian businesses over $80 million in a single year.

Phishing campaigns

Your domain is used in mass phishing campaigns targeting your customers or industry. Recipients trust the email because it appears to come from a known organisation.

Brand and reputation damage

Every spoofed email damages trust in your brand. If your domain ends up on spam blocklists due to misuse, legitimate email from your business stops reaching inboxes.

Explained simply

SPF, DKIM, and DMARC in plain English.

SPF

Who is authorised to send email as your domain?

Security risk

Missing or permissive SPF leaves your domain open to spoofing. Attackers can send phishing emails that appear to come directly from your business.

SPF (Sender Policy Framework) is a DNS TXT record that lists every mail server allowed to send email from your domain. When your email arrives at a recipient's server, that server checks your SPF record to confirm the sending server is on the approved list.

If you use Microsoft 365, your SPF record needs to include Microsoft's sending infrastructure (typically spf.protection.outlook.com). Without it, Microsoft 365 emails can fail SPF at the receiving end, increasing the chance they land in spam or get blocked.

A correctly configured SPF record with a hard fail (-all) policy tells receiving servers to reject any email that does not come from your approved senders. Attackers sending email as your domain will fail the check and their messages will be blocked or flagged.

DKIM

Can recipients verify your emails have not been tampered with?

Security risk

Without DKIM, emails from your domain can be modified in transit and your DMARC policy is less effective. Attackers can also forge sender details more easily.

DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign outgoing emails. Your mail server signs each email with a private key and the matching public key is published in DNS. Receiving servers use that public key to verify the signature.

For Microsoft 365, DKIM uses two selectors (selector1 and selector2) so Microsoft can rotate keys without interrupting email delivery. Both selectors need to be published in DNS and DKIM signing must be enabled in the Microsoft Defender security portal.

Without DKIM, emails can be modified in transit without any indication to the recipient. DKIM is also required for DMARC to function at full strength. A DMARC policy without DKIM signing in place offers considerably less protection.

DMARC

What happens when an email fails authentication?

Security risk

Without DMARC, receiving servers have no policy to follow when your domain is spoofed. Your brand can be impersonated in phishing campaigns with no visibility or recourse.

DMARC (Domain-based Message Authentication, Reporting and Conformance) works alongside SPF and DKIM. It tells receiving servers what to do when an email fails alignment checks, and it generates reports so you can see every server sending email as your domain.

There are three policy levels: p=none monitors only and takes no action, p=quarantine delivers failing emails to spam, and p=reject blocks them outright. Most organisations start at p=none to collect data, move to p=quarantine, then step up to p=reject once all legitimate email flows are confirmed.

DMARC reporting tags (rua= for aggregate, ruf= for forensic) give you a clear picture of every source sending email from your domain. That data helps you catch spoofing attempts and find misconfigured systems before they cause deliverability problems.

Common questions

Email security FAQ.

  1. What is SPF and why does it matter?

    SPF (Sender Policy Framework) is a DNS record that lists the mail servers authorised to send email on behalf of your domain. When a receiving server gets an email claiming to be from you, it checks your SPF record to confirm the sending server is on the approved list. Without SPF, anyone can send email pretending to be from your domain. Phishing attacks and invoice fraud both rely on this gap.

  2. What is DKIM and how does it protect my email?

    DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. Your mail server signs each message with a private key, and the matching public key is published as a DNS record. When a receiving server gets your email, it uses that public key to verify the signature, confirming the email came from your server and was not modified in transit.

  3. What is DMARC and what does p=reject mean?

    DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when an email fails SPF or DKIM checks. There are three policy levels: p=none monitors only and takes no action, p=quarantine delivers to spam, and p=reject blocks the email outright. p=reject is the strongest setting and gives the best protection against domain impersonation. DMARC also generates aggregate and forensic reports so you can see exactly who is sending email as your domain.

  4. What is Microsoft 365 DKIM and how do I enable it?

    Microsoft 365 includes built-in DKIM signing for your custom domain, but it is not enabled by default. You need to publish two CNAME records (selector1._domainkey and selector2._domainkey) pointing to Microsoft's signing infrastructure, then switch DKIM on in the Microsoft Defender admin portal. IronSights configures this as part of every Microsoft 365 security engagement.

  5. What is email spoofing and how does it lead to fraud?

    Email spoofing is when an attacker sends an email that appears to come from a legitimate domain, whether yours, your supplier's or your bank's. Without SPF, DKIM and DMARC in place, those emails reach inboxes with no warning. Common fraud patterns include business email compromise (BEC), invoice redirection and CEO impersonation scams. Australian businesses lost more than $80 million to BEC alone in a single year.

  6. My domain scored low. What should I do first?

    Start with SPF if it is missing. Once that is in place, enable DKIM signing in Microsoft 365, then add a DMARC record at p=none to collect reporting data before stepping up to p=quarantine or p=reject. IronSights can implement and test all three controls for your domain as part of a Microsoft 365 security review. Contact us for a free consultation.

  7. Does this tool store my domain or results?

    No. Running a domain check does not store any data. Your domain, score and results are only saved when you voluntarily submit the lead capture form to receive a report. See our privacy policy for full details.

IronSights

Ready to secure your email domain?

Our team configures SPF, DKIM and DMARC for Microsoft 365 organisations across Australia. We handle the technical implementation, monitor your DMARC reports and keep your configuration current as your environment changes.