Plain-English guide to custom-domain email

We often experience email as one bundled service, but custom-domain email has two separate jobs: receiving and sending.

To receive email, your domain's MX records tell the internet where incoming mail should be delivered. If those records point to MailLogic, MailLogic can receive mail for your domain and forward it to your Gmail inbox.

To send from your domain, recipient mail providers such as Gmail and Outlook need evidence that the message is authorized and authenticated. That is where SMTP configuration, SPF, DKIM, and DMARC come in.

MailLogic keeps those jobs separate. Forwarding handles the receiving side. SMTP handles the sending side. You can start with forwarding only, then add sending when you need it.

That small distinction removes a lot of confusion. Email is still full of old protocols and strange terminology, but this is the first mental model to get right.

When someone sends email to your custom-domain address, your domain's MX records decide where that message should go. If your MX records point to MailLogic, MailLogic receives the message and forwards it to your existing Gmail inbox.

That means you can keep reading email in Gmail. You do not need to check a separate mailbox just because you use an address on your own domain.

Receiving mail at your custom-domain address does not automatically mean Gmail can send from that address. For that, Gmail needs to send through an SMTP server authorized for your domain.

In Gmail, this is usually done with Gmail's “Send mail as” feature. You add your custom-domain address, enter the SMTP server details, and Gmail uses that SMTP connection when you send or reply from that address.

MailLogic acts as an automated SMTP routing layer.

When email is sent to your custom domain, your domain's MX records point the message to MailLogic. MailLogic receives the message, applies automated routing and spam checks, and forwards it to the destination you configured, such as your Gmail inbox.

When you send from Gmail using MailLogic SMTP, Gmail connects to MailLogic as the sending server. MailLogic then relays the message onward using your custom-domain sending identity.

This routing is automated. Human review is not part of normal message routing, filtering, or delivery.

For spam and abuse protection, MailLogic uses automated filtering tools, including Rspamd. These systems evaluate messages using programmatic signals such as sender reputation, authentication results, spam patterns, and delivery risk. The goal is to protect deliverability and prevent abuse without manually reviewing customer email.

MailLogic keeps operational logs for delivery troubleshooting, abuse prevention, and system reliability. These logs may include transport metadata such as sender and recipient addresses, routing direction, SMTP status codes, delivery responses, timestamps, and spam-scoring results.

MailLogic does not intentionally store email bodies or attachments in application logs. Message content may exist temporarily while the mail server is processing, queuing, forwarding, retrying, or bouncing a message. After normal delivery or queue expiration, the transient message copy is removed from the mail system.

In short: MailLogic is designed to route email automatically, inspect messages programmatically for spam and abuse, and retain only the operational metadata needed to keep the service reliable.

MX records tell the internet where email for your domain should be delivered.

When someone sends email to your domain, the sending mail server checks your domain's DNS records to find out where to deliver it. The specific DNS records used for incoming email are called MX records.

“MX” stands for mail exchanger, but the plain-English meaning is easier:

MX records are the delivery address for email sent to your domain.

MX records often have a number next to them, called priority. A lower number means higher priority. So an MX record with priority 10 is tried before one with priority 20.

Some services use multiple MX records so there is a backup path if one server is unavailable. For most users, the important part is not the number itself. The important part is that the MX records point to the right place.

This is also why changing MX records should be done carefully. MX records control incoming email for the domain. If you replace working MX records with the wrong ones, new email may stop arriving where you expect.

SPF, DKIM, and DMARC are three different email authentication mechanisms.

SPF checks whether the sending mail server is authorized to send email for a domain. In plain English, it answers to the question: “Was this email sent from a server that this domain allows?”

DKIM checks whether the message was cryptographically signed by a domain and whether the signed parts of the message were changed in transit. In plain English: “Did this message carry a valid domain signature, and does the message still match that signature?”

DMARC connects SPF and DKIM to the visible From address. It lets the domain owner tell receiving mail servers what to do when a message claims to come from that domain but does not pass aligned authentication.

In plain English, DMARC provides an answer to: “If an email says it is from my domain but cannot prove it properly, here is how you should handle it.”

Depending on the domain's DMARC policy, the receiving server may monitor the message, send it to spam, or reject it.

A domain should have one SPF record, not one SPF record for each service.

This becomes confusing because each email service may tell you to “add this SPF record.”

For example, one service may ask you to add:

v=spf1 include:_spf.google.com ~all

Another service may ask you to add:

v=spf1 include:mailservice.example ~all

And a third service may ask you to add:

v=spf1 include:another-service.example ~all

But you should not add three separate SPF records to the same domain. That can cause SPF to fail.

Instead, the SPF record needs to be combined into one TXT record:

v=spf1 include:_spf.google.com include:mailservice.example include:another-service.example ~all

This tells receiving mail servers that all three services are allowed to send email for your domain.

There is one more catch: SPF also has a DNS-lookup limit. Each “include” can trigger extra DNS lookups behind the scenes. If you add too many services, SPF can exceed that limit and fail even if the record looks correct.

So the rule is simple: keep one SPF record, combine services carefully, and avoid adding more sending services than you actually use.

DMARC passes when either aligned SPF or aligned DKIM passes. Both are not required.

If neither passes with alignment, the receiving system consults the domain's DMARC policy:

• p=none: take no DMARC-specific enforcement action; mainly monitor.
• p=quarantine: treat the message as suspicious, commonly placing it in spam.
• p=reject: reject the message.

These are published requests to receivers, not commands that every receiver must obey mechanically.

In particular, p=none does not mean discard. It means not quarantine or reject it because of the DMARC result.

SPF passing and SPF alignment are separate checks.

1. SPF passes when the sending IP address is authorized for the envelope sender domain, usually shown in the Return-Path or MAIL FROM.
2. SPF aligns when that envelope sender domain matches the domain in the visible From: address. Under DMARC's default relaxed alignment, a subdomain of the same organizational domain can also align.

DMARC counts SPF only when both are true.

For example:

• Visible From: [email protected]
• Return-Path: [email protected]
• SPF passes

SPF passes and the domains align, so SPF can satisfy DMARC.

But:

• Visible From: [email protected]
• Return-Path: [email protected]
• SPF passes for mailvendor.com

SPF authentication passes, but mailvendor.com does not align with example.com. SPF therefore does not satisfy DMARC.

Receiving mail providers such as Google and Microsoft send DMARC reports when your _dmarc TXT record includes an address in the rua field. The reports summarize the SPF and DKIM results for messages that claimed to come from your domain.

A new domain usually has little or no sending history. Gmail, Outlook, Yahoo, and other mail providers have not yet seen enough normal behavior from it. From their point of view, the domain may be authenticated, but still unfamiliar.

That is why a new domain can pass SPF, DKIM, and DMARC and still be treated cautiously.

The same is true when a domain's sending behavior changes suddenly. Email systems are conservative because spam and phishing are constant problems. Passing authentication is the baseline. Reputation is built over time.

Correct DNS proves that the domain is configured properly. It does not instantly prove that the domain has a trustworthy sending history.

When someone says “Gmail did not receive my email,” there are usually two different problems.

Either the message never reached Gmail, or Gmail received it and put it somewhere other than the inbox.

That distinction matters.

If you use MailLogic with Gmail, the receiving path usually looks like this:

sender → your domain's MX records → MailLogic → your Gmail inbox

So the first question is: where did the message stop?

Start with Gmail itself. Search for the sender, subject line, or a unique phrase from the message. Also check Spam, All Mail, Trash, category tabs, filters, and blocked addresses. Sometimes the message arrived, but Gmail did not show it in the inbox.

Next, check whether the sender received a bounce. A bounce message can show whether delivery failed, was rejected, or was delayed. The technical details are often more useful than the visible error summary.

Then check the custom-domain setup. Make sure the sender used the correct address.

Also make sure your domain's MX records point to MailLogic. MX records control where incoming mail for your domain is delivered. If they point somewhere else, MailLogic may never see the message.

Finally, check your MailLogic forwarding settings. The custom-domain address should exist in MailLogic, and the forwarding destination should be your correct Gmail address.

On paid plans, MailLogic's Log page can help narrow this down. If MailLogic received and forwarded the message, the log can show that. If the log does not show the message, the issue is likely before MailLogic: the sender, the address, or the domain's MX records.

The useful way to think about it is:

• If MailLogic never received the message, check the sender, address, and MX records.
• If MailLogic forwarded the message, check Gmail search, Spam, filters, and final placement.

There are three common ways to send email from a custom domain.

The right choice depends on what you are trying to do.

A web app means you log into a separate service, open another inbox or composer, and send email there. This can work, but it also means another interface to check and another workflow to maintain.

SMTP is different. SMTP lets an email app you already use send through an authorized mail server. For example, if you want to send from [email protected] inside Gmail, you usually use Gmail's Send mail as feature and enter SMTP credentials: server, port, username, and password.

That means Gmail stays your daily email app. MailLogic handles the sending path behind the scenes.

An API is for programming / software, not ordinary human email. Your app or script calls an endpoint to send messages automatically. This is useful for verification emails, notifications, receipts, alerts, or internal tools.

A simple way to choose:

• Use Gmail + SMTP when a person is writing or replying to email.
• Use the API when software is sending email automatically.
• Use a separate web app only if you actually want another place to compose and manage email.

Your root domain is usually best for your main business identity.

For example, if you are sending human-written email to customers, partners, contractors, or clients, using your root domain often makes sense. These are messages where the relationship matters and the email is usually composed or reviewed case by case.

Subdomains are usually better for app-generated or transactional email.

For example, you might send receipts, invoices, billing notices, password resets, login alerts, product notifications, or system updates from a subdomain.

The reason is separation. Automated emails can have different volume, formatting, bounce patterns, and user behavior from ordinary human email. Using a subdomain helps keep that activity separate from your main domain identity.

It does not make reputation risk disappear, but it gives you a cleaner boundary. Your root domain can remain focused on human business communication, while your app or system emails can run through a dedicated subdomain.

In MailLogic, a subdomain should be treated as its own email domain.

That means example.com and notify.example.com are separate setups.

If you add:

notify.example.com

then your app emails would come from addresses like:

[email protected]

not:

[email protected]

The subdomain needs its own DNS records for receiving and sending. That may include MX records, SPF, DKIM, and DMARC depending on how you use it.

SRS stands for Sender Rewriting Scheme.

It is one of the technical details that makes email forwarding work properly.

When an email is forwarded, the message is not being sent directly from the original sender to the final inbox anymore. It passes through the forwarding service first.

That creates a problem for SPF.

SPF checks whether the sending server is allowed to send for the envelope sender's domain. If Gmail receives a forwarded message from MailLogic, but the envelope still looks like it belongs to the original sender's domain, SPF may fail. MailLogic is not supposed to be listed in that sender's SPF record.

SRS solves this by rewriting the envelope sender during forwarding.

The visible From address stays the same, so you still see who originally sent the message. But the technical return-path is rewritten so the forwarded message can be authenticated as coming through the forwarding service.

In plain English:

• Forwarding changes the delivery path.
• SRS updates the technical sender information so SPF still makes sense.

This is why properly configured forwarding can work reliably with Gmail and other inboxes. Forwarding itself is not the problem. Problems usually happen when a forwarding service does not handle SPF, SRS, DKIM, and delivery behavior correctly.

For MailLogic, SRS is part of the forwarding path. It helps forwarded mail reach Gmail without making SPF fail just because the message was forwarded.