EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 10 Aug 2017, 05:39 AM   #1
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 554
How to handle DNS with Fastmail and (different) web host?

I use FM for email with my own domain. I also have a website using the same domain but hosted by an outside (not FM) webhost.

Currently I have DNS delegated to nameservers at my web host and then manually set MX records there pointing to FM for email.

Alternatively, one could delegate DNS to FM's nameservers and then set an A record to point to the IP address of my web site.

What are the advantages/disadvantages of each approach? 6 of one, half dozen of another? Or are there some specific reasons to prefer one over the other?
camner is offline   Reply With Quote

Old 10 Aug 2017, 09:26 AM   #2
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,519
If you can tolerate a small risk that a service failure makes rapid recovery from the problem impossible, it really does not matter. However, for those requiring a robust solution that is resilient against failure of a single service, I have long recommended the following.

Having registered your domain, park the DNS at a separate DNS management host (such as EasyDNS or ZoneEdit). The reason for the separation is that, should your DNS host fail, or be otherwise inappropriate for further use, you can use the site where you registered the domain to change to a new DNS host. If your domain registrar fails, this will not impact your DNS in the short term. One assumes there would be ways in the long term to establish your domain with a new registrar.

None of your websites, mail servers and other services are hosted at your domain registrar or DNS host. As a result, if any mail server or web host fails, you have the ability within a few hours, to establish the service elsewhere should you encounter a failure that you judge cannot be circumvented in another manner.

The above is not the simplest solution, but it avoids single points of failure that leave you without recourse. Some will be so confident of their provider that they may choose to register the domain and host all services in the same place. They are entitled to their opinion, but experience has made me very leery of assuming a single vendor deserves that much trust. The simplicity of that approach would appeal to me only for domains with services that I do not regard as mission critical.
BritTim is offline   Reply With Quote
Old 10 Aug 2017, 10:40 AM   #3
sflorack
The "e" in e-mail
 
Join Date: Feb 2002
Posts: 2,872
Quote:
Originally Posted by BritTim View Post
Having registered your domain, park the DNS at a separate DNS management host (such as EasyDNS or ZoneEdit). The reason for the separation is that, should your DNS host fail, or be otherwise inappropriate for further use, you can use the site where you registered the domain to change to a new DNS host.
Couldn't the same thing be achieved by having FM host his NS records, and then redirect if FM fails? Why involve a third party? (I've never used the DNS hosts you mentioned, but I'd personally rather have my domains managed by someone who has skin in the game.)
sflorack is offline   Reply With Quote
Old 10 Aug 2017, 11:23 AM   #4
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,519
Quote:
Originally Posted by sflorack View Post
Couldn't the same thing be achieved by having FM host his NS records, and then redirect if FM fails? Why involve a third party? (I've never used the DNS hosts you mentioned, but I'd personally rather have my domains managed by someone who has skin in the game.)
That would be possible, yes, but it would mean more steps are necessary for recovery. What you would be talking about is finding a new host for your DNS, and then directing this to your new mail service. Even should you decide to, again, combine your mail service and DNS together, recovery involves some additional complexity.

I take your point about "skin in the game", and I actually pay a small amount to my DNS hosts for 5-nines reliability. There is some value in using a specialist DNS management organization over a mail service that dabbles in DNS support. I am a firm believer in the "best of breed" principle.
BritTim is offline   Reply With Quote
Old 10 Aug 2017, 03:27 PM   #5
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,236
I agree that for critical business needs you should look for the best DNS host available. But so far I have had very good reliability with the free (for a Standard or better account) Fastmail DNS hosting. I also find it very easy to set up the DNS records needed for email and simple websites, since Fastmail automatically sets up:
  • A records for my domain website, subdomain website, and mail.mydomain redirection.
  • MX records for my domain email, subdomain email, and mail.mydomain.
  • CNAME records for DKIM signing sent through the Fastmail SMTP.
  • SRV records for SMTP, IMAP, and POP client auto-discovery by modern email clients.
  • SRV records for CardDAV contact sharing client auto-discovery.
  • SRV records for CalDAV calendar sharing client auto-discovery.
  • TXT SPF default record (which I disable and enter as a custom entry, since I want to force all outgoing traffic to be forced to the Fastmail SMTP).
  • I also use a custom DMARC entry through the Fastmail DNS host. I recently changed my policy from p=quarantine to p=reject, and I'm waiting to see if any problems show up.
  • Fastmail confirms if DKIM and SPF are correctly configured.
  • If you are using a non-Fastmail DNS host, I recommend that you configure all of these as recommended at:
    https://www.fastmail.com/help/receiv...d.html#dnslist
Bill
n5bb is offline   Reply With Quote
Old 11 Aug 2017, 12:06 AM   #6
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
I've gone back and forth on this a bit over the years, and really I mostly agree with what Bill says about FastMail's simplicity in that they configure all of the records for you, making it really easy to get everything up and running, especially if you're not experienced in the ways of DNS there are more records to deal with for an e-mail service than for a simple web host (as you can see from Bill's list above), so this is where FastMail excels.

Further, while BritTim's point about having to find another DNS provider in the event of failure is valid, depending on your registrar this may not be as big of an issue. EasyDNS, for example, offers basic DNS hosting with every domain registration, so if FastMail were to suffer a catastrophic failure, you could simply point your NS records back to the registrar and use them.

In my case, I've used FastMail off and on in the past but I've also gone back over to DynDNS, simply because they're "best of breed" for DNS hosting and I have the benefit of being grandfathered in on their standard DNS plan from when they were offering services for one-time payments about 15 years ago so it's completely free. Were that option not available to me, however, I'd likely just stay with FastMail's DNS.
jhollington is offline   Reply With Quote
Old 11 Aug 2017, 12:11 AM   #7
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
Quote:
Originally Posted by n5bb View Post
I also use a custom DMARC entry through the Fastmail DNS host. I recently changed my policy from p=quarantine to p=reject, and I'm waiting to see if any problems show up.
I've been using p=reject for a couple of years now with no issues whatsoever, although of course YMMV. The key is to make sure that your SPF record is set up correctly, of course, especially if you send mail from other third-party services using your own FROM address (for example, I send invoices from Freshbooks, so I've had to add their servers to my SPF records).

Quote:
Note that even if you're using a third-party DNS provider, you can go into the "Domains" section in your account settings and see if your DKIM and SPF records are correctly configured and view what the appropriate DNS entries should be for your domain as far as FastMail is concerned (click on "Show DNS Settings"). I find this approach a bit easier than the help article as it shows the entries specific to your actual domain, and you can just copy-and-paste into your actual DNS provider in most cases.
jhollington is offline   Reply With Quote
Old 11 Aug 2017, 02:31 AM   #8
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 554
Quote:
Originally Posted by n5bb View Post
I agree that for critical business needs you should look for the best DNS host available. But so far I have had very good reliability with the free (for a Standard or better account) Fastmail DNS hosting. I also find it very easy to set up the DNS records needed for email and simple websites, since Fastmail automatically sets up:
  • A records for my domain website, subdomain website, and mail.mydomain redirection.
  • MX records for my domain email, subdomain email, and mail.mydomain.
  • CNAME records for DKIM signing sent through the Fastmail SMTP.
  • SRV records for SMTP, IMAP, and POP client auto-discovery by modern email clients.
  • SRV records for CardDAV contact sharing client auto-discovery.
  • SRV records for CalDAV calendar sharing client auto-discovery.
  • TXT SPF default record (which I disable and enter as a custom entry, since I want to force all outgoing traffic to be forced to the Fastmail SMTP).
  • I also use a custom DMARC entry through the Fastmail DNS host. I recently changed my policy from p=quarantine to p=reject, and I'm waiting to see if any problems show up.
  • Fastmail confirms if DKIM and SPF are correctly configured.
  • If you are using a non-Fastmail DNS host, I recommend that you configure all of these as recommended at:
    https://www.fastmail.com/help/receiv...d.html#dnslist
Bill
Yikes! I don't think I know what half of these DNS records are for! In looking at my zone record, I see that the only DNS records I have related to email are two MX records pointing to FM and the following TXT SPF record:
Code:
"v=spf1 +a +mx +ip4:129.121.176.191 +ip4:108.165.20.5 +include:relay.mailchannels.net +include:spf.messagingengine.com ~all"
So I think this really answers the question as to which method to use for DNS when one's website is hosted at a different place than email. By delegating my DNS to the web host and then setting up MX records to FM, I'm not taking advantage of the various features FM provides. By reversing things so that I delegate DNS to FM and then set up a custom A record to point to my web host, I'll be able to let FM handle the appropriate zone records for email.

Two questions remain:
  1. You write
    Quote:
    TXT SPF default record (which I disable and enter as a custom entry, since I want to force all outgoing traffic to be forced to the Fastmail SMTP)
    Can you elaborate on what setting up a custom TXT SPF record accomplishes? When you say "force outgoing traffic to use FM's SMTP, " what circumstances are you talking about (obviously sending email via the FM web interface will use FM's SMTP, and using an email client will use the SMTP server set up in the config, right?). What kind of custom TXT SPF record accomplishes this?
  2. In a general way, what are the advantages of using the various "safety mechanisms" such as DKIM and DMARC for someone like me, who does not send bulk email or other kinds of email that could more easily be seen as spam?



Thanks to all who replied to my initial question!
camner is offline   Reply With Quote
Old 11 Aug 2017, 03:02 AM   #9
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
Quote:
Originally Posted by camner View Post
Yikes! I don't think I know what half of these DNS records are for! In looking at my zone record, I see that the only DNS records I have related to email are two MX records pointing to FM and the following TXT SPF record:
Code:
"v=spf1 +a +mx +ip4:129.121.176.191 +ip4:108.165.20.5 +include:relay.mailchannels.net +include:spf.messagingengine.com ~all"
Do you know why you have that SPF record set up the way you do? Right now, you're listing a few other servers as being allowed to send mail for your domain, which is fine if you're sending mail through other SMTP servers, but if you know you're only using FastMail to send mail, you can (and should) simplify that SPF record a bit to take out the two ip4 entries and the first include (relay.mailchannels.net).

On the flip side, if you do have a valid reason to use that SPF record, you'll need to disable FastMail's default SPF record and add that back in manually in your DNS setup at FastMail.

Quote:
Can you elaborate on what setting up a custom TXT SPF record accomplishes? When you say "force outgoing traffic to use FM's SMTP, " what circumstances are you talking about (obviously sending email via the FM web interface will use FM's SMTP, and using an email client will use the SMTP server set up in the config, right?). What kind of custom TXT SPF record accomplishes this?
The default SPF record that FastMail publishes looks like this:

Code:
v=spf1 include:spf.messagingengine.com ?all
The use of the question mark in "?all" at the end of this record tells receiving servers that the SPF record is actually "neutral," which means it really doesn't technically have any effect on receiving servers (or at least it shouldn't), so it technically renders the SPF record meaningless for all practical purposes. FastMail does this because they don't want to make any assumptions on behalf of their customers as to what other SMTP servers you might be using.

A more restrictive SPF record for sending messages through FastMail only would simply replace the "?all" with "-all" resulting in this:

Code:
v=spf1 include:spf.messagingengine.com -all
This change, often used in conjunction with a DMARC policy, tells receiving mail servers that messages from your domain should only come from FastMail's servers (spf.messagingengine.com is actually another SPF record that lists the specific servers used by FastMail to send messages). In this case, if a message originates with a FROM address at your domain name and is delivered by another server, it should be rejected, although this will depend upon how the receiving server implements its spam filtering and other policies, as well as what you've published in your own DMARC record.

To break it down, SPF records designate which servers are allowed to send mail on behalf of your domain, DKIM records contain the key used to "sign" messages from your domain, and DMARC records tell receiving servers what you want them to do if a message from your domain fails to match either the SPF or DKIM records.

Note that you can also use ~all, which is considered a "soft fail" —*again how this is handled depends on the receiving system, but it generally indicates that messages that fail the SPF record are more likely to be categorized as spam (given a slightly higher score), and be reported on, but less likely to be rejected outright.

Quote:
In a general way, what are the advantages of using the various "safety mechanisms" such as DKIM and DMARC for someone like me, who does not send bulk email or other kinds of email that could more easily be seen as spam?
The real issue isn't about whether you're sending bulk e-mail or spam, but more about preventing OTHER people from sending bulk e-mail or spam in your name. Proper SPF/DMARC/DKIM records help to prevent mail with your FROM address from being sent by anybody but you. How this is handled will vary based on how each receiving server looks at the SPF/DMARC records, but it generally ranges from simply a higher probability that such messages will be categorized as spam or otherwise suspect through to telling the other servers to reject such messages entirely as invalid.
jhollington is offline   Reply With Quote
Old 11 Aug 2017, 05:53 AM   #10
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 554
Quote:
Originally Posted by jhollington View Post
Do you know why you have that SPF record set up the way you do? Right now, you're listing a few other servers as being allowed to send mail for your domain, which is fine if you're sending mail through other SMTP servers, but if you know you're only using FastMail to send mail, you can (and should) simplify that SPF record a bit to take out the two ip4 entries and the first include (relay.mailchannels.net).
It took me a bit of sleuthing to figure out the answer to your question, because I was quite sure I hadn't added that SPF record myself!

That SPF record was added at the zone record for my domain at my webhost, who handles my name servers. The two IP addresses reverse DNS lookup to the web host's domain (asmallorange.com). The entry for messagingengine.com was added automatically by the web host, probably because I had manually added MX records pointing to FM. "mailchannels.net" is a service used by my webhost to handle part of their email security.

As far as sending mail through non-FM SMTP servers is concerned, I'd certainly rather not! But, there were historical reasons why I had to. When I first got an iPhone, FM didn't have an iOS app, and the mail app built into iOS handles IMAP in a way that was very user unfriendly (I have lots of folders set up, and navigating back and forth within the iOS app to look at specific IMAP folders is a pain!). So, I had all email sent to mydomain.com forwarded by FM to a Gmail address, and then I used the iOS mail app to read all email via the Gmail inbox. I was able to set things up at Gmail to use an address at mydomain.com as the "From" address, and I could set things up so that Gmail used the FM SMTP server, but the net effect of this was that whenever I used the "share" button on my iPhone to send a link or something else, the iPhone would use the Gmail SMTP server and not the FM server. I never did figure out a way to work around that.

BUT, now that FM has an iOS app, I don't have a Gmail account set up on the iPhone, so all email gets sent out via the FM server.
camner is offline   Reply With Quote
Old 11 Aug 2017, 06:34 AM   #11
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 554
How to set up the right A records at Fastmail...

So, now the question is how to set up the A records at FM for my non-FM website so that things work. As I look at the Zone records for my domain at my web host, I have a lot of A records, for things like subdomains as well as ftp. What I have noticed is that all of those A records all point to the same IP address. So, I'm thinking all I should have to do is to have two A records at FM, as follows:

mydomain.com IN A xxx.xxx.xxx.xxx (where xxx.xxx.xxx.xxx is the IP address of the web host)
*.mydomain.com IN A xxx.xxx.xxx.xxx

The second is to handle ftp, subdomains, www., etc.

Can it be this simple?
camner is offline   Reply With Quote
Old 11 Aug 2017, 06:40 AM   #12
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,519
Avoid wildcard DNS records unless you are an expert. They do not work the way most people expect.

Use either separate A records or separate CNAME records. Even if there are many of them, it only takes a couple of minutes to set them all up
BritTim is offline   Reply With Quote
Old 11 Aug 2017, 09:22 AM   #13
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 554
Quote:
Originally Posted by BritTim View Post
Avoid wildcard DNS records unless you are an expert. They do not work the way most people expect.

Use either separate A records or separate CNAME records. Even if there are many of them, it only takes a couple of minutes to set them all up
Thanks for the tip.

Aside from the additional lookup time, is there a functional difference I should care about between:

Code:
mydomain.com A ip addr
ftp.mydomain.com A same ip addr
and

Code:
mydomain.com A ip addr
ftp.mydomain.com CNAME mydomain.com
camner is offline   Reply With Quote
Old 11 Aug 2017, 10:30 AM   #14
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,519
Quote:
Originally Posted by camner View Post
Thanks for the tip.

Aside from the additional lookup time, is there a functional difference I should care about between:

Code:
mydomain.com A ip addr
ftp.mydomain.com A same ip addr
and

Code:
mydomain.com A ip addr
ftp.mydomain.com CNAME mydomain.com
The general rule I use is that, if I know a particular subdomain will always be the same as the root domain, I use an CNAME. Otherwise I use an A record. This minimizes potential unexpected behavior during future updates.

One thing you should never do, unless following instructions of your service provider in very unusual situations, is to CNAME your root domain to another domain. Use an A record for the root domain unless quite sure a CNAME is correct. I have seen CNAME records appear to work for a while and then result in very strange behavior in this case.
BritTim is offline   Reply With Quote
Old 11 Aug 2017, 10:51 AM   #15
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
Quote:
Originally Posted by BritTim View Post
One thing you should never do, unless following instructions of your service provider in very unusual situations, is to CNAME your root domain to another domain. Use an A record for the root domain unless quite sure a CNAME is correct. I have seen CNAME records appear to work for a while and then result in very strange behavior in this case.
Actually, you should never use a CNAME record for a root domain, ever. As they say, it's not just a good idea, it's the law

CNAME records are simply not permitted at the root domain level for all practical purposes. Technically speaking, as per RFC 1034, the only scenario in which a CNAME record at the root level would ever be acceptable is in the scenario where you have NO other resource records in that particular domain, which would be an extremely rare and specific situation.

For the same reason, you should never use a CNAME record in conjunction with any other records. So, don't use a CNAME and an A record for the same hostname (e.g. www.mydomain.com). In short, if you're using a CNAME record for a given entry, it should be the only record for that entry.

It's also best to avoid using CNAMEs as targets of other record types. This is especially true for MX and NS records (e.g. you can't have an MX pointing to a CNAME — MX records should always point to A records), but it can be an issue with other record types as well.
jhollington is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 09:32 AM.

 

Copyright EmailDiscussions.com 1998-2013. All Rights Reserved. Privacy Policy