We're using an email sending service (fairly known) to send our emails. We made DNS changes so that emails going through them would pass SPF and DKIM.

A few days ago we noticed that they allow any account with them to send emails on behalf of domains that do not belong to that account. For example, let's say my domain is mycompany.com, and now I want to add mycompetitor.com to my account. This service would now allow me to send emails from @mycompetitor.com.

I brought this up with them and their solution was to no longer "sign" the email, but still allow me to add whatever domain I want. So now I can still send from @mycompetitor.com except that Gmail, for example, would show "via email-sending-service.com". SPF and DKIM would still pass, and the email is not marked as spam.

So, am I being paranoid? I feel that using this email service it would allow anybody with an account to send emails that sort of look like they come from us.

They argue that this is "standard practice" and that anybody with a box somewhere could do the same. But, would SPF/DKIM still pass in those cases?

I feel that by making DNS changes I authorize this email sending company to send emails on my behalf, and then the company goes ahead and allows anybody with an account to send on my behalf (without the signing part); am I off?


1 Answer 1


SPF on your domain is not about preventing you from sending forged emails; it is about preventing other people from sending emails with your domain. To be more precise, if you own domain foo.com, you can document in SPF that "every email which purports to come from an @foo.com address should exit from machine smtp.foo.com and none other". Email servers who receive an email with an alleged sender with an @foo.com address may then lookup the SPF records and check whether the email seems to come from the legitimate server (yours) or some other.

SPF processing is not mandatory so it is up to each email server to enforce it, at their leisure.

The SPF records on your domain (foo.com) will not prevent you from sending an email with a fake address, e.g. an address ending with @bar.com. In that case, it would be the SPF records on the bar.com domain which matter.

DKIM has a somewhat similar goal. When your server uses DKIM, then it signs every email that goes through it. The DNS for your domain documents that fact, and publishes the public key (the one used to verify the signature). Supposedly, when an email server receives an email with an @foo.com sender, that server will see your DKIM key in the DNS, and thus verify the signature. If the signature is absent or does not correspond to the mail contents, then the receiving email server will know that something is amiss.

There again, DKIM processing is up to each email server. And, there again, nothing in your domain will prevent you from sending emails with @bar.com as alleged sender -- but if the bar.com owner uses DKIM himself, your forgery will be revealed.

Summary: the DNS rules related to SPF and DKIM, added to the domain foo.com, document how an email should normally be sent/signed when it pretends to be sent by someone with an @foo.com address. The DNS rules in foo.com tell nothing whatsoever about emails which claim to originate from another domain.

  • Using your example, I authorize this service (X) to send emails from foo.com. Now some bad guy comes along, makes an account with X, and adds foo.com as their domain. They can now send emails that look like foo.com except for the signing part (shows up as "via x.com" in Gmail). Could the bad guy have done the same without X's help?
    – pbz
    Apr 9, 2013 at 20:29
  • "Authorizing" the "X" service to send emails from foo.com means adding in the DNS records of foo.com the information: "under normal conditions, an email bearing sender's address @foo.com can exit from X". This "allows" X to send mails in your name; or, more accurately, it forbids all other people except X from sending mails in your name. But it does not help against forgeries from X itself. Apr 9, 2013 at 20:57
  • Exactly, so their "anybody with a server can do this anyway" argument is not valid, correct?
    – pbz
    Apr 9, 2013 at 21:06
  • 2
    SPF and DKIM are exactly meant to prevent "anybody with a server" to do the same, indeed. Since SPF and DKIM are not mandatory (yet), forged emails still exist, but if X does what you describe, then X is misbehaving (X does exactly what SPF and DKIM were designed to prevent: sending emails with forged sender addresses). Apr 9, 2013 at 21:10
  • isn't that unsecure though? Since DNS responses can be trivially spoofed? The DKIM public key could be replaced by any MITM attacker. Feb 4, 2017 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .