1

I have been able to confirm that bad actors are sending emails from nonexistent subdomains of my company's primary domain.

Let's say my primary domain is foo.com. Email is sent from that base domain from my own mail system. Due to partnerships with a helpdesk provider, a e-commerce (storefront) company, and a CX/NPS provider, I also have three valid unique subdomains from which email comes from each (shop.foo.com, support.foo.com, and feedback.foo.com.

I have full DMARC w/ DKIM for all 4. With the invaluable assistance of DMARCian (a DMARC report aggregation & reporting service), I have confirmed that there are several sources of recurring email from other subdomains - ones that do not exist. For example, some unauthorized and unknown entity in VN is sending email from news.foo.com & enews.foo.com. Another source is sending from sales.foo.com. This last one is particularly of concern because the content of the few emails from this bad actor we've been forwarded is quite damaging to my company (we think it's a foreign competitor in our fierce niche market behind it).

Unfortunately, my current DMARC polices are either monitor or quarantine; I can't use a reject policy (that's another battle.)

I am considering creating SFP & DMARC records for these nonexistent subdomains, with no allowed senders and a reject policy.

I'm not sure how effective this would be though. I also cannot think of any drawbacks, other than a bit of extra work to set it up and then maintain it when the bad actors start using different bogus subdomains. We're always one step behind the bad guys, eh?

So... are there any drawbacks to what I am considering doing that I have not thought of? And do you think it's worth the effort? Or is there a better approach to dealing with these bogus subdomains?

CaptainZack
  • 11
  • 2

4 Answers4

3

The main problem here is that fighting email forgery is a job of both the sender and the recipient. If the recipient is accepting mail from non-existent hostnames, it's likely that they won't check SPF, DKIM or DMARC, either. Also, the path of adding these records would be endless, if they were required.

DMARC

You claim you have full DMARC, but p=none or even p=quarantine aren't fully enforcing DMARC policies. If you can't apply a strict policy for your domain, but could do it for submains, the sp tag (RFC 7489, 6.3) might help you out.

sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the p tag defined above. If absent, the policy specified by the p tag MUST be applied for subdomains. Note that sp will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism described in Section 6.6.3.

As you told you have DKIM in place for all the subdomains sending mail, your policy could be e.g.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=reject;"

If you had some subdomains you use for sending mail, but can't use reject, you can override the sp=reject with an explicit less strict policy for the subdomain:

_dmarc.no-dkim.example.com. IN TXT "v=DMARC1; p=quarantine;"

SPF

Let's assume a recipient won't accept email from non-existent hostnames, like it should be. As SPF doesn't inherit like DMARC, you need a corresponding SPF TXT record for every existing A record. If you don't intend to send mail from sub.example.com at all, it would be:

sub.example.com. IN TXT "v=spf1 -all"

Or, if the host itself could send mail from @sub.example.com:

sub.example.com. IN TXT "v=spf1 +a -all"
Community
  • 1
Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • You can also create a wildcard TXT record, e.g. as `v=spf1 a -all` (the `+` is implicit), that will be used as the default when there isn't a more direct record (like the ones for hosts that actually send mail and have their own TXT records, most notably `@`). – Adam Katz May 27 '20 at 15:29
  • 1
    A wildcard `TXT` would add the record only to non-existing subdomains i.e. the ones that don't need them. – Esa Jokinen May 27 '20 at 16:05
  • That is incorrect. A wildcard TXT record would add the record only to subdomains that do not have their own TXT records. This is irrespective of whether they have A or CNAME records (which is what I assume you mean by "existing"). That's the whole point. – Adam Katz May 28 '20 at 15:09
  • I think we might be both right, but on a different level. [RFC 4592, 2.1](https://tools.ietf.org/html/rfc4592#section-2.1) defines this as I've told: e.g. ([2.2.1](https://tools.ietf.org/html/rfc4592#section-2.2.1)) an existing `host1.example. A` will terminate a different type record `*.example. MX` i.e. the record SET must be empty for the wildcard to work, and e.g. BIND follows this definition. On the other hand, e.g. Microsoft's DNS implementation works as you have told. – Esa Jokinen May 28 '20 at 15:20
  • Interesting! Thanks for the clarification. I thought it was just A/AAAA/CNAME that trumped wildcards for each other since they're basically interchangeably used for host→IP resolution. A is a fallback for MX, so I wouldn't be surprised that to work too (though mail servers are very particular about DNS and wildcards regarding MX records are not a good idea). – Adam Katz May 28 '20 at 15:31
  • Just tested this with BIND 9.11 and I was correct: `foo.example.com. A` indeed overrides `*.example.com. TXT`, so your solution won't work on BIND. – Esa Jokinen May 28 '20 at 15:50
  • Hah, the above is all a wild goose chase. The SPF section of this answer is not relevant at all. SPF has no enforcement mechanism and nobody should block mail on it without DMARC, yet DMARC defaults to blocking everything, therefore not needing SPF. – Adam Katz May 28 '20 at 22:07
  • SPF has an enforcement (`-` Mechanisms), but SPF and DMARC protects different things. You do need SPF to protect your domain from being used as the *envelope sender*, but only DMARC can protect the `From` header. Also, if SPF passes because you don't have proper policies, DMARC passes, too. – Esa Jokinen May 29 '20 at 03:37
  • I work in anti-spam. SPF technically has an enforcement mechanism, but it gained a feedback mechanism too late to be useful (theory meets practice: you'll get **massive** false positives blocking on SPF failures). DMARC _is_ SFP's enforcement mechanism. If SPF is not defined, it cannot pass. The SMTP `mail from` (envelope sender) is not visible to the recipient and therefore is not a big spoofing risk. DMARC can use SPF to verify a sender with header alignment, but you're right: it can't enforce an envelope forgery. – Adam Katz May 29 '20 at 14:18
  • That's true, but then there's also a bigger picture: if organization A only use SPF and organization B only use DMARC+DKIM, the domain of B can be used as an envelope sender while spoofing the From header as organization A. Seeing different unrelated domains in `From` and `Return-Path` of a spam email has become really common. – Esa Jokinen May 29 '20 at 15:23
  • I'm merely saying DMARC can stop unwarranted subdomain mail (in From headers) without engaging SPF or DKIM. Forged `mail from` doesn't matter because the recipient won't see it and there's no usable enforcement mechanism for it (though yes, env/header mismatches exist in 25% of all mail). – Adam Katz May 29 '20 at 21:12
0

you can to setup SPF -all and DMARC reject policy for those identified bogus subdomains, to prevent spoofed emails from reaching those ESP mailboxes which check SPF/DMARC. But this is not a long term solution.

It make sense to work on moving whole domain to reject, if possible. I fully understand the challenge, since myself is in DMARC world for last 4+ years. Can I help somehow with that ?

btw, here is a good tool that help you to check how different ESP handle spoofed emails coming from domain protected with DMARC reject -> https://dmarc-tester.com.

E.g. Microsoft put spoofed emails to Spam, Yandex is not DMARC aware, so place them into Inbox

Zonder
  • 84
  • 4
  • Fortunately, it's possible to [enforce DMARC `p=reject` on O365](https://security.stackexchange.com/q/226270/70406), but the recipient has to do it. – Esa Jokinen May 26 '20 at 18:22
  • @EsaJokinen thank you for pointing me to good post. Just implemented that rule in Exchange Online and got the rejection delivery report – Zonder May 29 '20 at 10:57
  • I'm glad to hear that the answer I wrote there was helpful to someone. :) – Esa Jokinen May 29 '20 at 10:59
-1

In a more generalized case in which you have arbitrary subdomains that need to send DMARC-valid mail despite abuse from other arbitrary subdomains (regardless of whether they exist), you can control outbound mail with an SMTP smart host that DKIM-signs the mail it sends. Using relaxed DMARC alignment, mail with a From header using the domain in question (or any subdomain) would be blocked by DMARC unless it is signed by this smart host or else another DKIM or SPF setup.

Your goal would be to have a DMARC record like this*:

v=DMARC1;p=reject;sp=reject;adkim=r;rua=blah@dmarcian.com;

* Note that you can't start with reject policies! You must start with p=none;sp=none or p=quarantine;sp=quarantine and review the reports that come to the rua= address to ensure you aren't blocking legitimate mail.

sp=reject (which is implied by p=reject but we're making explicit for clarity) ensures that the subdomain policy defaults to reject unless that subdomain has its own DMARC record.

adkim=r (which is the default but is explicitly present here again for clarity) ensures that matching alignment for DKIM can be relaxed (matching by paid-level domain is sufficient; see the links above for relaxed alignment).

Stand up a dedicated mail relay through which all subdomain mail must pass. This mail relay must authenticate its users to avoid open relay issues. It also offers the ability to toggle between different DKIM selectors on a per-account basis, letting you control multiple paid-level domains with proper segregation.

With all valid subdomains independently passing DMARC or else sending mail through an aligned DKIM-signing smart host, you should be safe to upgrade to p=reject;sp=reject, but you must observe DMARC reports for some time before making that change.

Community
  • 1
Adam Katz
  • 869
  • 8
  • 16
  • This doesn't make any sense: sending all mail using plain organizational domain nor through a single host is completely unrelated to the problem described. It's a) not required by any standard b) nor would stop anyone else from using any subdomain. – Esa Jokinen May 28 '20 at 18:29
  • I am not suggesting rolling up the From domains to use the plain organizational domain. Just the `d=` part of the DKIM-Signature header. This migrates control of all subdomains' outbound mail to the smart hosts' authentication system since DMARC `p=reject` would prevent any other mail from the domain. If a system sends mail without the smart host, it is rejected by DMARC. The smart host would be configured to relay mail from any FQDN authorized by the account used for authentication. – Adam Katz May 28 '20 at 20:13
  • That might solve *some* problems. Just not the one this question is about. – Esa Jokinen May 28 '20 at 20:19
  • You're right, I've abstracted too far, addressing a wildcard-like solution. I rewrote this answer to better address the abstracted solution I came up with, but it's likely not relevant to the specifics of this question. – Adam Katz May 28 '20 at 22:05
-1

You can do p=quarantine;sp=reject for your paid-level domain (which DMARC calls Organizational Domain) and then create individual p=quarantine records for subdomains you want to send mail.

sp=reject indicates a subdomain policy to reject mail without aligned SPF or DKIM. It is overridden by any DMARC record for the exact subdomain FQDN, thus needing the individual records noted above.

As you proposed, you could alternatively create DMARC p=reject records for each observed invalid domain as listed by your DMARC reports, though that might feel like whack-a-mole if those fake host names change regularly.

 

Side note: SPF authorization (or else DKIM verification) is only needed to enable something to pass DMARC. If you just want to reject everything, you need neither SPF nor DKIM:

A domain without SPF or DKIM will always trigger its DMARC policy.

Community
  • 1
Adam Katz
  • 869
  • 8
  • 16