Page MenuHomePhabricator

Updating DNS records
Closed, ResolvedPublic


The Communications team recently signed on with MuckRack a PR software that allows us to research reporters and email them directly from the platform; this was approved by legal and finance. This will really help streamline any media pitches we do. In order for the emails (media pitch notes) that we send from the platform to appear as though they came directly from Samantha Lien or I, they required us to update our DNS records with the attached information (see below). Appreciate your help with this - if I need to direct the request elsewhere please let me know. Thank you. - Anusha Alikhan

Here is the info on updating the records:


Related Gerrit Patches:

Event Timeline

AAlikhan created this task.Aug 27 2019, 9:08 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 27 2019, 9:08 PM
AAlikhan triaged this task as Normal priority.Aug 27 2019, 9:08 PM
BBlack changed the task status from Open to Stalled.Aug 27 2019, 9:24 PM
BBlack added subscribers: MoritzMuehlenhoff, mark, faidon, BBlack.

Holding on this until early next week, as we have too many decision-makers on vacation this week, and there are policy and security implications to granting DKIM for to a third party via Amazon SES.

Varnent added a subscriber: Varnent.

@BBlack - any updates?

mark added a comment.Sep 5 2019, 2:32 PM

Hi Anusha, Greg,

Looking into this. Unfortunately it seems the way this is being implemented, we would effectively be signing away complete control of our email security settings/policy for to a set of third party companies. I'm afraid that's rather problematic, because specifically is one of our project domains, and our main infrastructure domain and as our primary corporate email domain, and a lot of things depend on the (email) security of that domain. This would allow these third parties to set arbitrary security policies for that domain, and for example allow for any of our email addresses or staff members to be impersonated (which is actually what seems to be desired here, yet in a very restricted way).

Because (unfortunately) this is the primary domain historically used for all corporate mail as well as infrastructure, a lot of security sensitive procedures depend on the email security of, e.g. generation of TLS certificates and other aspects that protect the privacy and security of both our global users and our staff/organization. Therefore handing over full control of this for domain to third parties is high risk. As it is proposed now, through either a malicious attempt (e.g. a compromise) or even an unintentional configuration mistake it may be possible for anyone to gain control of it and impersonate addresses, which could have grave consequences. And we would have not even have visibility into it when that happens, no control over it, and may never realize it happened.

Would it perhaps be possible to find an alternative or compromise to (mostly) achieve the benefits you're looking for without requiring this highly risky implementation using For example, without being exhaustive or having deeply researched these, right now I can see the following alternatives:

  • Would it be possible to use another email domain than; either a subdomain (e.g. or anything else you pick that is not yet in use) or another domain altogether (perhaps is suitable)? We should be able to make those email domains work as aliases for specific staff members and make them look entirely legit that way.
  • Or, would it be possible to have the required DomainKey (DKIM) records installed by us in our DNS instead of CNAMEd to them, and also limited/scoped to only a restricted set of e-mail addresses? For example, we could authorize MuckRack to send out emails for only some specific addresses, e.g. some Communications team members, and no others. This would however require support/cooperation from MuckRack.
  • Or, would it be possible for MuckRack to send out emails via our corporate email relays instead of their own / AmazonSES perhaps? This would also alleviate the issue, but again would require their support/cooperation.

I'm sorry to have to make this difficult, but specifically that domain really limits what we can do in a many ways. Hopefully in the future we are able to split these functions (corporate email, wiki project domains, and infrastructure domain) over multiple disjunct domains, so we can be much more flexible and lower our risks altogether.



mark changed the task status from Stalled to Open.Sep 5 2019, 2:32 PM

@mark - Thank you very much for that thoughtful and helpful reply!

Talking it over, we would like to try the first option if you believe that will work.

So how do we go about getting this setup?

Anusha Alikhan

Samantha Lien

From MuckRack:




AAlikhan added a comment.EditedSep 9 2019, 7:58 PM

Hi @mark - Just checking in on the above. Thanks.

mark added a subscriber: herron.Sep 12 2019, 12:54 PM

@mark - Thank you very much for that thoughtful and helpful reply!
Talking it over, we would like to try the first option if you believe that will work.
So how do we go about getting this setup?
Anusha Alikhan
Samantha Lien

I believe that will work, yes.

@herron Could you please take this? See the above; implement as a mail-only domain with the above aliases in Exim for a few communications team members, aliasing to their normal (gmail) addresses. Then once that works, install the above CNAME records for DKIM to MuckRack so they are allowed to send mail for that domain only. Thanks!

herron claimed this task.Sep 12 2019, 2:27 PM

Change 536313 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] exim: add to wikimedia_domains

Change 536318 had a related patch set uploaded (by Herron; owner: Herron):
[operations/dns@master] dns: add mail records for

@mark you bet! I've uploaded a few patches to get mail flowing for this subdomain.

@Varnent were there any SPF records provided by muckrack/ses? Also could you please verify that the below aliases look good? To the left is the user-part for, and on the right is the destination.


Change 536318 merged by Herron:
[operations/dns@master] dns: add mail records for

Change 536313 merged by Herron:
[operations/puppet@production] exim: add to wikimedia_domains

mark added a comment.Sep 17 2019, 12:25 PM

What's the status of this? Is this done and working?

Aliases have been added, dns records are live, and test mail to myself works. Please see for currently open follow-up questions.

Thank you! I tested and it's working.

jbond added a subscriber: jbond.Sep 18 2019, 4:34 PM

From MuckRack:

do you know when the DNS records were added? We don't see any of them returning as valid on our side just yet.

Possible to share a screen shot of how those records were added so our team can provide feedback if needed?

DNS records were added Monday at approx. 10:30am Eastern.

Here is what I'm seeing in terms of responses from live DNS:

$ host -t MX mail is handled by 10 mail is handled by 50
$ host -t TXT descriptive text "amazonses:QeZasSSTVw5sDiCQmdzG4z4UuLgkRtceplXtv2SI2BY="
$ host is an alias for
$ host is an alias for
$ host is an alias for

@herron : There's now two log entries in the /var/log/exim4/paniclog on related to DKIM, not sure whether we need to tweak something still or whether that's harmless noise (if it's the latter, it should ideally not spam paniclog):

2019-09-19 00:30:06 1iAkKj-00026a-WE DKIM: signing failed: RSA_LONG_LINE
2019-09-19 02:27:31 1iAmAM-0006eB-NK DKIM: signing failed: RSA_LONG_LINE
Varnent closed this task as Resolved.Sep 24 2019, 8:13 PM

Appears they got it working - thank you!! :)