Phishing in the name of your domain: How third-party senders can impersonate you

Recently, several business partners of one of our clients were contacted by a deceptively realistic-looking email. The content: A short message referring to an allegedly attached PDF – professionally formatted, with a full signature, company logo, and even imprint data.

What appears to be a legitimate message at first glance turned out upon closer inspection to be a targeted phishing email – aimed at enticing recipients to open a harmful document or link.

But how was it possible for such an email to be sent in the name of the sender max.mustermann@absender-domain.at, even though:

• the affected mailbox was not compromised,

• Multi-Factor Authentication (MFA) in Microsoft 365 was active,

• and the email did not appear in the “Sent” folder?

Analysis: What happened?

Upon checking the full email headers, we found:

• The email was actually sent via Microsoft 365 – with valid SPF, DKIM, and DMARC checks.

• The sender appeared to be legitimate (max.mustermann@absender-domain.at).

• However, there were no traces in the original account – the email did not come from the own tenant.

A foreign Microsoft 365 tenant was used to abuse the domain absender-domain.at. This was possible because the DNS protection mechanisms of the domain were not restrictive enough.

Why this is dangerous

Without complete protection mechanisms in the DNS zone of a domain, third parties can send emails in the name of your domain – even through legitimate services like Microsoft 365 or Google Workspace.

In the case of max.mustermann@absender-domain.at, this was possible because:

• SPF was correct, but not sufficient.

• DKIM was only active over the Microsoft subdomain, not for the own domain.

• DMARC was only running in “Monitoring Mode” (p=none) – thus provided no protection.

The solution: Properly configure SPF, DKIM, and DMARC

To effectively protect against spoofing, phishing, and identity theft, the following DNS technologies are essential:

SPF (Sender Policy Framework)

Defines which mail servers are allowed to send on behalf of your domain.

DKIM (DomainKeys Identified Mail)

Adds a digital signature to each outgoing email that can be verified by the recipient. Important: Activate your own DKIM key for your domain, not just the one from e.g., Microsoft.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Specifies what recipients should do if SPF or DKIM fail:

• p=none → just monitor

• p=quarantine → mark as spam

• p=reject → reject (recommended)

💡 Pro Tip: DMARC Monitoring Made Easy with Postmark

If you do not want to build your own infrastructure for analyzing DMARC reports, you can use services like Postmark (https://dmarc.postmarkapp.com/) as a practical service. Postmark automatically receives your daily DMARC reports and prepares them visually and understandably, including SPF/DKIM results and IP analyses.

Conclusion: Protect your domain – not just your mailbox

Many companies believe that with MFA and strong passwords everything is secured. But protection starts one level deeper – with your domain configuration. Only with correctly set up SPF, DKIM, and DMARC records can you ensure that only authorized systems are allowed to communicate on behalf of your company.

The good news: Once set up correctly, these measures require very little maintenance – and in addition to increasing security, they also enhance the deliverability of your legitimate emails.

Do you need assistance?

We would be happy to analyze your domain configuration or take over the complete securing for you – including setup, activation, and monitoring.

👉 Contact us before someone else does it in your name ;)