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 an inbox you already use.

To send from your domain, recipient mail providers such as Gmail and Outlook need evidence that the message is authorized and authenticated. MailLogic can send through its dashboard, Batch Send, APIs, or authenticated SMTP, with SPF, DKIM, and DMARC supporting the sending identity.

MailLogic keeps those jobs separate. Forwarding handles incoming mail. The sending features handle outbound mail. You can start with free 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.

MailLogic has no fixed monthly limit on the number of messages it forwards, on any plan. Forwarding is subject to fair use.

This is separate from the number of named addresses in your plan. A named address is an address such as [email protected] that you create and manage individually. The Free and SMTP plans support five named addresses, Starter supports 15, and Founder supports 50.

Catch-all receiving is different again. When catch-all is enabled, mail for otherwise unconfigured addresses can be forwarded to the destination you choose without creating every possible address first.

So the short version is:

• Forwarding volume has no fixed monthly limit, subject to fair use.
• Named-address limits depend on the plan.
• Catch-all can receive other addresses without turning each one into a named address.

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. Receiving and sending use separate paths.

During Google's 2026 transition period, Gmail's third-party “Send mail as” feature can still connect to MailLogic SMTP. Google has announced that this feature will end in January 2027 and may restrict new configurations before then. See Google's announcement.

This change does not stop MailLogic from forwarding incoming mail to Gmail. For outbound mail, use Send Email or Batch Send in the MailLogic dashboard, an API where included, or a compatible email client or application configured with your MailLogic SMTP credentials.

A subdomain is a name added in front of your root domain, separated by a dot. Examples include www.example.com, mail.example.com, and billing.example.com.

MailLogic can use a subdomain just like a root domain. A subdomain can have its own sending and receiving setup, separate from the root domain.

For example, example.com can continue using Google Workspace or Microsoft 365, while mail.example.com is managed through MailLogic for SMTP, API, Batch Send, or forwarding.

MailLogic recognizes when a domain is a subdomain, understands its relationship to the root domain and adjusts the DNS setup instructions accordingly.

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.

For outgoing mail, MailLogic accepts messages from Send Email, Batch Send, the sending APIs, or an authenticated SMTP client and relays them 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.

MailLogic Replies is a deliberate exception. For a supported Replies conversation, MailLogic stores the original subject plus inbound and outbound reply subjects and bodies for the bounded retention period shown in the dashboard. The original outbound body and attachment contents are not copied into Replies. Inbound attachment contents are also not stored; the conversation records only that attachments were present. When the retention period ends, the stored conversation content is purged while limited routing, delivery, deduplication, and audit metadata may remain.

In short: normal routing is automated and application logs contain operational metadata rather than message bodies. Conversation content is retained only when the user selects or uses a feature that supports MailLogic Replies, and only for its stated retention period.

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 is operationally important.

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.

MailLogic provides four sending paths. They use the same authenticated domain identity, but they are designed for different jobs.

Dashboard Send Email is for composing a message directly in MailLogic. Use it when one or more recipients should receive the same content. You can add up to 100 recipients across To, Cc, and Bcc, choose plain text or HTML, preview the message, and attach up to 25 MB of files.

Batch Send is for separate personalized transactional messages. Upload or paste a CSV, use its column names as template variables, preview the rendered result, and then queue up to 100 recipients on SMTP, 500 on Starter, or 2,000 on Founder. Batch Send does not support attachments.

Authenticated SMTP is for a compatible email client or application. The client connects using the server, port, username, and password shown in MailLogic. Each named sending address has its own SMTP credentials.

The APIs are for software. The Send API handles ordinary programmatic transactional messages. The Batch Send API accepts an asynchronous personalized batch and provides an endpoint for checking its progress and delivery outcomes.

A simple way to choose:

• Use Send Email for a message you want to compose and send now.
• Use Batch Send when values such as a name, month, reference, or amount change for each recipient.
• Use SMTP when another email client or application should do the composing.
• Use an API when software should initiate the send.

Send Email, Batch Send, and authenticated SMTP are available on every paid plan. The Send API and Batch Send API are available on Starter and Founder.

Batch Send combines one message template with a CSV recipient list. Every CSV row becomes a separate email rather than one message with a large To or Bcc list.

A small recipient file might look like this:

email,name,month,amount
[email protected],Alice,August,$42
[email protected],Bob,August,$58

The template can refer to those columns using double braces:

Subject: Your {{month}} account summary

Hi {{name}}, your current amount is {{amount}}.

Before sending, MailLogic checks the CSV, verifies that every variable has a matching column and value, identifies previously suppressed recipients, and lets you preview rendered messages. A batch can contain up to 100 recipient rows on SMTP, 500 on Starter, or 2,000 on Founder.

Each sendable row uses one SMTP credit. Suppressed recipients are skipped and do not use credits. MailLogic reserves credits for the complete sendable set before processing, so a credit shortage does not cause only part of the batch to be sent. A batch waiting for a manual credit purchase can resume within its 24-hour retention window.

After dispatch begins, the recent-batches view separates progress from delivery outcomes. A progress value such as 100 / 100 means that all rows finished the dispatch stage. It does not mean that every destination accepted the message. Check the Accepted, Deferred, Pending, Bounced, Failed, and Suppressed counts for the transport results.

MailLogic Replies is a dashboard conversation view for supported messages sent through MailLogic. It lets you read a recipient's response and continue the exchange without creating another mailbox.

Dashboard and API Batch Send create a separate tracked conversation for each sendable recipient. For dashboard Send Email, you can select MailLogic Replies under Reply-To when sending to exactly one To recipient with no Cc or Bcc. The recipient's response then appears in the Replies section, where you can respond from the original custom-domain address.

MailLogic Replies does not create conversations for ordinary Send API requests or messages submitted directly through authenticated SMTP. If you choose one of your forwarding addresses as Reply-To instead, responses follow that forwarding route to your existing inbox.

Replies is not a general-purpose mailbox. It handles only these supported conversations. Stored reply subjects and bodies are available for the bounded retention period shown in the dashboard and are purged after that period. Attachment contents are not stored, although the conversation shows when attachments were present.

Sending has more than one stage. First, MailLogic accepts and submits the message. Later, the destination mail server reports whether it accepted the recipient, temporarily deferred the attempt, or rejected it.

• Submitted: MailLogic accepted the message for outbound processing.
• Accepted by destination or Sent: the destination mail server accepted the message.
• Deferred: the destination temporarily refused the message and the mail server is retrying.
• Pending: no conclusive destination result is available yet.
• Bounced: the destination returned a permanent rejection.
• Failed: submission or delivery failed, or the retry period expired.
• Unknown: MailLogic could not confirm whether submission succeeded.
• Suppressed: MailLogic skipped the recipient before submission because of qualifying earlier failures.

“Accepted by destination” is the strongest result an SMTP sender normally receives, but it is not proof that the message appeared in the inbox. The receiving provider can still place it in Spam, apply a filter, or otherwise classify it after acceptance. MailLogic does not claim that an Accepted result proves inbox placement or that the recipient read the message.

On paid plans, Logs show forwarding and SMTP activity with searchable filters, detailed responses, dates, and CSV download. Batch Send also summarizes recipient-level outcomes with the batch.

Repeatedly sending to an address that cannot receive mail wastes sending capacity and can damage delivery reputation. MailLogic therefore keeps a workspace-wide suppression list for qualifying delivery failures from MailLogic-managed sends.

A clear permanent recipient failure, such as an address that does not exist, can suppress the recipient immediately. Other ambiguous or soft final failures require failures from two separate messages. A temporary deferral does not count as a suppression failure, and MailLogic does not suppress an address merely because of a policy rejection, content rejection, authentication problem, connection problem, or local submission error.

A later successful delivery clears non-permanent failure history. A clear hard-bounce suppression remains until someone deliberately restores the address.

Once an address is suppressed:

• Batch Send skips it and does not use a credit.
• Send API removes it from the sendable recipient set; a mixed request can continue for other recipients.
• Dashboard Send Email warns you and requires an explicit confirmation to override the protection.
• MailLogic Replies blocks a response to the suppressed recipient.

The Suppressed recipients table below Logs shows the address, reason, and last failure. Use Restore only after confirming that the address is valid and ready to accept mail again.

Automatic suppression currently covers dashboard Send Email, Send API, Batch Send, and MailLogic Replies. Messages submitted directly by an external client through authenticated SMTP can appear in Logs, but those direct SMTP submissions do not currently create automatic recipient-suppression state.

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

For example, if you are sending 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.